내가 관련된 것 같다 2 개 다른 질문을 검토 한 :DDD | 계층 구조 (같은 유형) | 제약
- Is Aggregate Root with Deep Hierarchy appropriate in DDD?
- How to define DDD Aggregate root for hierarchical data structure?
그러나 그들이 바로 내 상황과 동일하지 않은; 어쩌면 "제약"측면을 놓친 것일 수 있습니다.
내 상황 : 나는 "연구"라는 AR을 가지고 있으며 연구는 클러스터별로 구성 될 수 있습니다 (조사 도메인의 클러스터 샘플링 개념에서 빌림).
이 "Study"에서이 매개 변수 "clusteringDepth"(정수)가 생성자라고 가정 해 보겠습니다. 세 가지를 지정합니다 (지방, 카운티, 도시).
그건 그냥 사양입니다. 연구. 실제로 연구를 수행 할 때 연구에 기반한 StudyPlan의 인스턴스를 만듭니다.
그래서이 경우 나는 주 (일등급 클러스터) 목록이있는 StudyPlan 인스턴스를 갖게됩니다. 각 주에는 카운티 목록 (2 차 수준 클러스터)이 있고 각 카운티에는 도시 목록 (3 차/최종 수준 클러스터)이 있습니다.
각 클러스터에는 할당량 정보와 날짜 범위 (해당 클러스터에서 발생시키는 인터뷰 수와 인터뷰 날짜 간격 지정)를 첨부 할 수 있습니다. 분명히 상위 클러스터는 "하위 클러스터의 쿼터 합계가이 클러스터의 쿼터보다 작거나 같아야합니다"와 같은 불변 조건을 유지해야합니다.
좋습니다 ... 이제 제약 조건 : 응답자와의 인터뷰를 계획 할 수 있습니다. 이를 위해 InterviewPlan의 인스턴스를 만듭니다. 하지만 ...이 인터뷰 계획은 터미널 (3 단계) 클러스터에만 첨부 할 수 있습니다.
물론 제약 조건을 쉽게 구현할 수 있습니다 (예 : 클러스터의 addInterviewPlan 메소드에서 클러스터에 부모 또는 아니요가 있는지 확인).
하지만 ... 웬일인지 ... 나는 이것이 훌륭한 DDD 디자인이 아니라고 생각합니다. 이 제약은 너무 기술적으로 들린다. 그것은 정상적인 도메인 대화에서 자연스럽게 가지 않습니다.
내 질문 : DDD "언어 유동성/자연 조건"을 과도하게 해석하고 있습니까? 또는 ... 나는 개념을 놓치고 있는가? 내 말은, 다른 도메인 모델을 만들어야한다는 것인데, 이는 클러스터의 자식이 될 수 있으며 인터뷰 플랜을 가지고있는 것일까 요?
감사합니다,
Raka기타 관련 : http://git.net/ml/programming.domain-driven-design/2006-06/msg00028.html
는 클러스터링을 발명 했는가 또는 도메인 전문가가 당신에게 그 말처럼 tehnical 것을 의미? – plalx