DDD 집계 루트 선택

Question

시간 추적 응용 프로그램 작성 집계 루트를 디자인하는 가장 좋은 방법을 결정하려고합니다.

기본 핵심 엔터티는 클라이언트, 프로젝트, 직원, ProjectAssignment, 부서, 작업 표입니다. 클라이언트에는 하나 이상의 프로젝트가 있으며 프로젝트에는 ProjectAssignment를 통해 할당 된 직원이 한 명 이상 있고 직원이 부서에 속하고 작업 표가 Project, Employee를 함께 연결합니다.

클라이언트가 확실한 집계 루트처럼 보입니다. 내가 가지 가장 좋은 방법이 될 것이다 갈 모르겠어요 다른 집계에 관한

Client -> Project -> ProjectAssignment -> Employee 

...

나는 생각했다 ...

Department -> Employee -> Person 

또는 가지고 직원 및 부서는 전적으로 별도의 집계. 직원은 한 부서에만 있고 한 부서에만있을 수 있습니다. 그러나 부서는 부서 계층을 작성하기 위해 자체 참조합니다.

집계 루트간에 공유되는 개체를 어떻게 처리합니까?

Answer 1

집계를 설계 할 때 경계 된 컨텍스트와 불변성을 고려해야합니다. 내가 이해 한 바에 따르면 하나의 경계가 된 컨텍스트 만 토론으로 가져 왔습니다. 직원이 하나의 부서에만있을 수 있다고 지정한 invariant 정보. 집합 루트 (AR)에 대한 내용은 Client, Project, Employee 및 Department입니다.

ProjectAssignment은 고용 ID 및 할당 날짜와 같은 기타 데이터의 목록을 보유하는 Project AR의 값 객체 여야합니다.

Timesheet은 의 값 객체와 의 목록과 시작일 및 종료일과 같은 기타 데이터를 포함 할 수 있습니다.

Employee AR은 직원이 하나의 부서에만 속한다는 불변 조건을 적용하는 참조 번호 Department ID을 보유 할 수 있습니다.

Answer 2

DDD는 데이터 구조 나 구조 간의 관계가 아니라 이러한 데이터 및 변경 사항 주위의 경계에서 발생하는 변경 사항에 관한 것입니다. DDD는 사람들이 단순한 응용 프로그램을 작성하고 단일 사용자에 초점을 맞추고 최대한 많은 DDD 원칙을 부과하려는 pluralsight 과정이나 회의를 포함하여 많은 장소에서 매우 잘 설명되지 않습니다.

도메인 기반 디자인의 핵심 원칙은 경계입니다. 집계를 찾으려고 할 때 먼저 응용 프로그램에서 수행하는 프로세스와 그 프로세스를 일관성있게 유지하기 위해 필요한 것이 무엇인지 생각하십시오. 이 변경을 수행하고 집계에서 다른 필요한 엔티티 (값 객체)로 감싸는 단일 엔티티를 작성하십시오. 그런 다음 하나의 엔티티를 해당 엔티티로 실행되는 모든 프로세스의 게이트 키퍼로 승격하십시오.

데이터 구조에서 디자인을 시작하는 것이 사람들이 DDD에서 실패하는 첫 번째 이유입니다. 당신이 제공 한 것부터 저에게, 합계는 ProjectAssignment이고, 아마도 Timesheet 일 것 같습니다. 왜냐하면 여기서 핵심적인 비즈니스 로직을 세울 것이기 때문입니다.다른 모든 것들은 간단하고 까다로운 스타일의 접근 방식으로 생성 될 수있는 값 객체 (orm을 사용해야하는 경우 엔티티)입니다. 엔티티와 가치 객체 간의 차이점에 대한 많은 토론과 블로그 글이 있습니다. 사람들은 도메인에있는 '객체'에 의미를 부여하는 경향이 있지만 도메인 전문가에게는 만들 시간을 많이 소비하는 소중한 객체는 가치에 불과합니다. Client 또는 Department을 집계 루트로 승격시키지 마십시오. 단지 값입니다.

두려워하지 마십시오. 도메인을 설계 할 때 여러 가지 사항을 고려하면 도메인 내보내기를위한 가치 객체 일 것입니다. 그들은 단지 그들을 사용하여 실제 사업체에 대한 작업을 수행합니다. 그들은 Client이 어떻게 생성되었는지, 어떻게 Department이 생성되었는지 또는 계층 구조가 어떻게 만들어 지는지 신경 쓰지 않습니다. 그들은 단지 그들을 만들고 편집하거나 삭제할뿐입니다. 따라서 Client 또는 Department을 설명하는 데 사용되는 단어는 단지 작성, 업데이트 또는 삭제 일 뿐이며 이러한 단어는 유비쿼터스 언어 (도메인 언어)의 후보가 아닙니다. 유비쿼터스 언어는 DDD에서 과소 평가 된 패턴입니다. 그것을 올바르게 사용하면 시간을 절약 할 수 있습니다. 물건을 디자인하는 데 소비하는 시간은 비즈니스에 중요하지 않습니다. 매번 무언가를 만들거나 무언가를 업데이트해야한다고 생각할 때마다 crud를 사용하십시오! DDD 원칙을 사용하여 자신을 괴롭히지 마십시오. 왜냐하면 생성이나 업데이트와 같은 단어에 대해서는 간단하지 않기 때문입니다.

DDD는 도메인 전문가에게만 액세스 할 수있는 경우에만 공동 작업 도메인에서만 빛을 발합니다. 동시에 비즈니스 전문가와 개발자 모자를 갖는 것은 정말로 어렵습니다. 최소한 그룹으로 또는 적어도 쌍으로 디자인을 만들고, 어떤 일이 일어날 지 시험해보십시오. 알맞은 ddd 디자인을 만드는 것만으로도 내 경험에서 거의 항상 실패 할 것입니다.

Answer 3

집계 루트를 선택할 때 트랜잭션 일관성과 최종 일관성 중에서 선택하십시오. 비즈니스 규칙에 따라 최종 일관성을 선호하게됩니다.

직원 및 부서를 살펴 보겠습니다. 사용 사례를 확인하십시오. 부서/직원 변경시 궁극적 인 일관성을 사용하는 것이 좋습니다 (사용자가 구형 구조를 때때로 볼 것에 동의합니까?)

예를 들어 부서 및 직원을 개별 집계로 처리하십시오. ID를 통해 직원 참조 부서를 만듭니다.

(예 : 사용자가 작업 표 보고서에서 직원에 대한 잘못된 분배를 허용하지 않는 경우) Department를 Employee 엔티티 컬렉션을 보유하는 집계로 만듭니다. https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577