DDD에서 유효성 검사 응용 프로그램 논리입니까, 아니면 도메인 논리입니까?

26

DDD를 사용하여 양식을 모델링한다고 가정하십시오. 이 양식에는 특정 종류의 비즈니스 규칙이있을 수 있습니다. 학생이 아닌 경우 소득을 지정해야하며 결혼했음을 나타내는 경우 자녀를 기재해야합니다. 국가를 지정한 경우 유효한 국가가 있어야합니다.

이러한 종류의 유효성 검사가 도메인이나 응용 프로그램 계층에 있습니까? 내가 고려하고 있던 다른 문제들 :

Laravel과 같은 특정 프레임 워크는 요청이 컨트롤러에 도달하기 전에 입력의 유효성을 검사 할 수있는 유효성 검사 규칙을 제공합니다. 해당 수준에서 유효성 검사를 수행하면 DDD가 중단됩니까?
국가가 유효한지 확인하는 경우 일반적으로 전 세계 모든 국가의 데이터베이스 테이블을 쿼리합니다. 그러나 DDD에서 이것은 도메인 계층에서 수행 될 가능성이 높습니다. 도메인 계층이 DB에 액세스 할 수 있습니까, 아니면 SQL 이외의 검색을 사용하여 유효한 국가를 결정해야합니까?
응용 프로그램과 도메인 계층에서 입력의 유효성을 검사해야합니까?

domain-driven-design

— 엑스트라 쿤
소스

6

당신은 질문에 항상 모든 것을 넣을 수있는 올바른 장소가 있다고 가정합니다. 없습니다.

— Robert Harvey

1

@RobertHarvey가 말한 것. "응용 프로그램"의 유효성 검사에 관계없이 유효성 검사는 항상 모델에 있어야합니다 (응용 프로그램의 모델 부분이 아닙니까?). "응용 프로그램"의 모든 유효성 검사는 모델의 유효성 검사를 반복하는 것만으로 UI의 응답 성을 향상 시키거나 "응용 프로그램"논리에만 관련되어야합니다. .. ",하지만 엔터티 유효성 검사를 가정했습니다). 도메인 유효성 검사를위한 "응용 프로그램"계층을 절대 신뢰하지 마십시오. 클라이언트가 정보를 전송하지 못할 수도 있습니다.

— Marjan Venema

29

이러한 종류의 유효성 검사가 도메인이나 응용 프로그램 계층에 있습니까?

신청. 당신이 원하는 마법의 검색어는 부패 방지 계층입니다

일반적으로 응용 프로그램에서 수신 한 메시지는 약간의 DTO입니다. 반부패 계층은 일반적으로 도메인이 인식 할 가치 유형을 만듭니다. 도메인 모델로 발송 된 실제 명령은 유효한 값 유형으로 표현됩니다.

예 : DepositMoney 명령에는 금액과 통화 유형이 포함될 수 있습니다. DTO 표현은 아마도 금액을 정수로 표현하고 통화 코드를 문자열로 표현합니다. 반부패 계층은 DTO를 예치 값 유형으로 변환하는데, 여기에는 유효 금액 (음수가 아니어야 함) 및 유효 통화 코드 (도메인에서 지원되는 코드 중 하나 여야 함)가 포함됩니다.

명령을 도메인 모델이 이해하는 유형으로 구문 분석 한 후에는 명령이 도메인에서 실행되며 비즈니스 불변을 위반한다는 이유로 근거로 명령을 거부 할 수 있습니다 (계정이 존재하지 않고 계정이 차단됨) 이 특정 계정은 해당 통화를 사용할 수 없습니다? 등).

다시 말해, 부패 방지 계층에서 입력의 유효성을 검사 한 후 도메인 유효성 검사에서 비즈니스 유효성 검사가 수행됩니다.

검증 규칙의 구현은 일반적으로 값 유형의 생성자 또는 값 유형을 구성하는 데 사용되는 팩토리 메소드 내에 있습니다. 기본적으로 객체의 구성이 유효하도록 보장하고 한 곳에서 논리를 분리하며 프로세스 경계에서 호출하도록 객체의 구성을 제한합니다.

— VoiceOfUnreason
소스

왜 신청이 답입니까? 귀하의 텍스트에 따르면 공식적인 유효성 검사는 도메인 또는 응용 프로그램과 도메인의 비즈니스 유효성 검사에서만 수행 할 수 있습니다.

— inf3rno

@ inf3rno 도메인과 관련이없는 양식의 유효성 검사에 대한 질문이 구체적으로 제기 되었기 때문에

— timetofly

1

이 대답은 의미가 없습니다. DDD의 부패 방지 계층은 외부 (다른 시스템의) 도메인 모델과 DDD 기반 응용 프로그램의 도메인 모델로 /에서 변환하기 위해 작성하는 추가 코드입니다. 이러한 외부 시스템이 없으면 반부패 계층이 없습니다. 또한 비즈니스 규칙 유효성 검사는 응용 프로그램 계층이 아닌 도메인 모델 (및 도메인 계층)에 속합니다. DTO의 경우 이는 DDD 앱에 있거나 없을 수있는 기술 구성 요소 (응용 프로그램 계층에 있음)입니다. DTO와 엔터티 / 값 개체 간 변환은 부패 방지 계층과 관련이 없습니다.

— 로제 리오

5

문제 도메인 모델에 도메인 비즈니스 규칙이 포함되어 있습니다. 비즈니스 규칙은 모델 요소에 대한 제약입니다. 엘리베이터가 문을 연 상태로 움직이지 않고 부패하기 쉬운 물품은 냉장되지 않은 용기에 적재되지 않으며 취소 된 주문이 배송되지 않음을 의미합니다.

그렇다고해서 도메인이 화면, 양식 등을 통해 사람과 상호 작용할 때 확인이나 도움이 필요하지 않다는 의미는 아닙니다. 선택 사항임을 인식하십시오.

비즈니스 규칙에는 개체의 특성을 제한하는 속성 규칙과 개체 간의 공동 작업 추가 및 제거를 제한하는 공동 작업 규칙의 두 가지 유형이 있습니다.

비즈니스 규칙은 프로그래밍 언어와 관련된 논리 규칙과 다르며 값이 제공되었으며 null이 아닌지 확인합니다.

참고 : DDD에는 양식 "모델링"에 대한 개념이 없습니다.

— 아리에
소스

0

특정 상태가 모델 엔터티를 유효하지 않게합니까? 그렇다면 모델은 엔티티가 해당 상태에 도달하지 못하게해야합니다. 즉, 모델은 자체 검증 방법을 알아야합니다.

그러나 약간의 문제가있다 : 모델 검증은 종종 너무 늦게 일어난다. 종종, 우리는 검증을 일찍하기를 원하기 때문에 사용자는 너무 오래 기다릴 필요가 없습니다. 그렇기 때문에 종종 유효성 검사가 응용 프로그램 논리에 적용됩니다.

유효성 검사 컨텍스트와 관련하여 엔터티가 추가 데이터를 쿼리 할 수있는 문제는 없습니다. 그러나 이러한 데이터의 출처는 중요하지 않습니다. SQL, File에서 온 것인지 아니면 하드 코딩 된 것인지 상관하지 않습니다. 이것이 리포지토리가 존재하는 이유입니다. 도메인은 필요한 쿼리 종류를 정의하고 다른 사람이 구현을 처리하도록합니다.

— 기분 좋은
소스

-2

도메인 계층에는 모든 유효성 검사 논리가 포함되어야합니다. 프레젠테이션, 부패 방지 계층 또는 기타 종속 계층이이를 반영해야합니다.

— 배리 패슨
소스