이 경우 두 가지 유형의 유효성 검사를 분리해야한다고 생각합니다. 도메인 유효성 검사 및 응용 프로그램 유효성 검사 .
응용 프로그램 유효성 검사는 명령 속성 'text'가 20 ~ 200 자 사이인지 확인한 경우 보유한 것입니다. 따라서 GUI와 POST 후에 서버에서 실행되는 view-model-validator를 사용하여이를 검증합니다. 전자 메일도 마찬가지입니다. (btw,`32.d + "Hello World .42"@ mindomän.local "과 같은 전자 메일이 RFC에 따라 유효하다는 것을 알고 싶습니다.)
그런 다음 다른 유효성 검사가 있습니다. 기사가 존재하는지 확인-GUI에 주석을 첨부하는 명령이 실제로 전송 된 경우 기사가 존재하지 않아야하는 이유를 스스로에게 질문해야합니다. GUI가 결국 일관성이 있었으며 데이터 저장소에서 물리적으로 삭제할 수있는 집약 루트 기사가 있습니까? 이 경우 명령 핸들러가 집계 루트를로드하지 못하므로 명령을 오류 큐로 이동하면됩니다.
위의 경우 포이즌 메시지를 처리하는 인프라가 있습니다. 예를 들어 메시지를 1 ~ 5 회 다시 시도한 다음 메시지 모음을 수동으로 검사하고 관련 메시지를 다시 배포 할 수있는 위치 큐로 옮깁니다. 모니터링하는 것이 좋습니다.
이제 우리는 논의했습니다 :
응용 프로그램 검증
- GUI에서 자바 스크립트 사용
- 웹 서버에서 MVC 유효성 검사
집계 루트 + 포이즌 큐 누락
도메인과 동기화되지 않은 명령은 어떻습니까? 어쩌면 도메인 로직에 기사에 대한 5 개의 주석 후에 400 자 미만의 주석 만 허용되지만 한 사람이 5 번째 주석에 너무 늦어서 6 번째가되어야한다고 말하는 규칙이있을 수 있습니다. 명령을 보내는 시점에서 도메인과 일치하지 않았습니다.이 경우 도메인 로직의 일부로 '유효성 검증 실패'가 발생하여 해당 실패 이벤트를 반환합니다.
이벤트는 메시지 브로커 또는 사용자 정의 디스패처에 대한 메시지 형식 일 수 있습니다. 응용 프로그램이 모 놀리 식인 경우 웹 서버는 언급 된 성공 이벤트와 실패 이벤트를 동 기적으로 수신하고 적절한보기 / 부분을 표시 할 수 있습니다.
많은 유형의 명령에서 실패를 의미하는 사용자 지정 이벤트가있는 경우가 종종 있으며,이 이벤트는 웹 서버의 관점에서 구독하는 경우입니다.
우리가 작업하고있는 시스템에서 MassTransit + RabbitMQ 메시지 버스 + 브로커를 통해 명령 / 이벤트로 요청-응답을하고 있으며이 특정 도메인 (일부 워크 플로우 모델링)에 이벤트가 있습니다 InvalidStateTransitionError. 상태 그래프에서 가장자리를 따라 이동하려고하는 대부분의 명령으로 인해이 이벤트가 발생할 수 있습니다. 우리는 궁극적으로 일관된 패러다임 후에 GUI를 모델링하고 있으므로 사용자를 '명령 수락'페이지로 보낸 후 웹 서버의보기를 이벤트 구독을 통해 수동으로 업데이트 할 수 있습니다. 우리는 또한 전체 뿌리에서 이벤트 소싱을 수행하고 있으며 또한 가스를 위해 일할 것임을 언급해야합니다.
따라서 많은 검증은 실제 도메인 로직이 아니라 실제로 애플리케이션 유형의 검증입니다. 도메인은 단순하지만 DDD를 수행하는 경우 간단한 도메인 모델을 갖는 데 아무런 문제가 없습니다. 그러나 도메인 모델링을 계속하면 도메인이 처음 나온 것만 큼 간단하지 않을 수 있습니다. 대부분의 경우 집계 루트 / 엔티티는 명령으로 인한 메소드 호출을 승인하고 유효성 검증을 수행하지 않고도 상태의 일부를 변경할 수 있습니다. 특히 웹 서버에서 명령을 유효성 검증하면 명령을 신뢰하는 경우 당신은 통제합니다.
Norwegian Developer Conference 2011 에서 DDD에 대한 두 가지 프레젠테이션 과 Öredev 2010 에서 Greg의 프레젠테이션을 볼 것을 권합니다 .
건배, 헨케