DDD : 몇 개의 집계가 필요합니까?

Question

저는 DDD에서 Aggregate 루트 개념과 약간 혼동합니다. 이론에 따르면 현재 작업과 관련된 집계가 있어야합니다.

예를 들어 회사를 나타내는 root 계정이 있습니다. 주소, 계정에 속한 사용자 및 기타 속성이 있습니다.

그리고 여러 페이지가 있습니다. 하나는 이름, 전자 메일, 전화 번호 등과 같은 일반 정보를 관리하는 것입니다. 다른 주소를 유지하는 것입니다. 모든 사용자를 표시하고 계정 개체 아래에있는 사용자 정보를 편집하려면 한 번 더 추가하십시오.

첫 번째 경우에는 주소에 신경 쓰지 않습니다. 두 번째로는 이름, 전자 메일에 신경 쓰지 않습니다. ..

2 개의 별도 계정 개체가 필요합니까? 아니면 하나의 계정 만 필요합니까?

그래서, 예를 들어, 나는 수업으로 끝낼 수 있습니다 (이 모델은 내가 설명보다 더 복잡 할 수 있음) : BasicAccountInformation, AccountAddress, AccountUsers .... 또는 단지 하나의 모든 데이터가 포함 된 계정?

올바른 DDD 접근 방식은 무엇입니까? 내가 생각하기에, 한 가지 경우에 나는 많은 속성과 논리를 포함하는 매우 복잡한 클래스를 얻을 것이다. 또는 클래스 당 2-10 개의 속성을 가진 많은 수의 간단한 클래스.

Answer 1

얼마나 많은 집계가 필요합니까?

적어도 하나.

집계는 일관성 경계로 사용됩니다. 전체 도메인을 단일 집계로 모델링하고 비즈니스 불변식이 각 쓰기에 의해 유지되도록하는 "집계 루트"하나를 제공하는 경우 좋은 방법입니다.

글쎄, 천천히가는 것이 좋다. 집계 루트는 집계 경계의 모든 주에 대한 일종의 직렬화 병목 현상을 제공합니다. 모델의 두 부분을 "동시에"업데이트하려고한다면 비즈니스 불변량에 대한 책임을 분할해야합니다.

페이지가 있습니다. 하나는 이름, 이메일, 전화와 같은 일반 정보를 관리하는 것입니다 ... 또 하나는 주소를 유지하는 것입니다.

보고서는 훌륭합니다. 모델을 위해 수집해야하는 데이터를 알려줍니다.

그러나 집계의 주요 관심사는 데이터를 읽거나 표시하거나보고하지 않고 쓰는 것이 아닙니다.

을 수행 할 때 함께 그룹화해야하는 모델에서 데이터를 찾아 집계를 찾습니다. 비즈니스 불변성을 시행하기 위해 필요한 데이터는 무엇입니까?

당신의 모델 상태의 대부분은 나머지 것들과 독립적이기 때문에 휴리스틱은 CRUD 도메인을 빨아 먹는 경향이 있습니다.

엔티티 관계를 볼 수 있습니다. 두 개의 집계가 엔티티를 "공유"한다면 그 엔티티는 세 번째 집계에 속할 것입니다.

당신이 볼 수있는 또 다른 사항은 엔티티 라이프 사이클입니다. 하위 엔티티가 집계 루트에서 오래 머물 수 있다면 잘못 모델링 한 것입니다.

당신이 묘사 한 바를 근거로, 여기서는별로 도움이되지 않습니다. 당신은 사실 계정을 가지고 있고, 그 안에 사는 것들을 잔뜩 가지고 있습니다.

가끔은 모든 것이 실패하고 "어떤 데이터를 한 번만로드 할 것인가"라는 추론을 사용하게됩니다. 그러면 키 값 저장소로 밀어 넣고 비즈니스 가치를 제공하는 것으로 돌아갑니다.