루트 엔티티를 가리키는 DDD/Aggregate Root/Member 엔티티

Question

집합 루트의 구성원 엔티티가 루트 엔티티를 가리키는 것이 좋습니까?

Population AR (Population은 루트 엔티티이고 PopulationMembership은 구성원 엔티티 중 하나임)이 있다고 가정합니다.

저는 Population과 PopulationMembership 사이의 연관 방향을 평가하고 있습니다. 다른 쪽 엔티티 인 Person (자신의 AR, PopulationMembership에는 Person에 대한 참조가 있음)이 있습니다.

ER (데이터베이스) 세계에서 우리는 일반적으로 PopulationMembership에서 Population (인구와 사람 사이의 다 대다 관계에서 연결 테이블 인 population_membership)을 가리키는 연결을 만듭니다.

그러나 나는 DDD 세계에서 그 습관을 깨고 인구 집단 (PopulationMembership)을 향한 인구 (개념 모델에서)를 지적해야한다고 생각합니다.

어쨌든, 그 전에는 (어떤 다른 상황에서) 우리가 구성원 엔티티에서 루트 엔티티로의 연결을 허용하는지 확인하고 싶습니다.

의견이 있으십니까?

Answer 1

좋아,의 두 부분으로이 질문을 분할하자 멤버 개체가 집계 루트에 대한 참조를 유지하는

1. 는 확인이 있습니까?
2. 일반 집계 모델링 규칙

의 1에서 시작하자 :

아니, 일반적으로 자식 개체가 집계 뿌리에 대한 참조를 유지하지 않아야합니다. 집계 루트는 집계 전체에 대한 진입 점이며 일관성 경계를 유지해야합니다. 즉, 집계에 대한 모든 변경 사항은 루트 엔티티 (루트 엔티티의 메소드를 호출하여 oop에 있음)를 통해 전달되어야합니다. 집계 루트는 하위 엔티티에 대한 참조를 반환 할 수 있지만 일시적이어야합니다. 또한 클라이언트는 집계 루트 외부의 하위 엔티티에 대한 변경을 수행해서는 안됩니다. 그렇지 않으면 일관성을 위반할 수 있습니다. 이를 염두에두고, 저는 자식 엔티티가 루트에 대한 참조를 보유하는 이유를 실제로 보지 못합니다 (클라이언트의 관점에서 볼 때 루트에 이미 액세스 할 수 있습니까?). 지금 당장 볼 수있는 유일한 예외는 모델을 특정 요구 사항 (예 : 프레젠테이션 계층에 의미있는 JSON 출력을 생성하기 위해 루트 엔터티 ID가 필요함)로 변환해야하는 경우입니다. 그러나 이러한 경우라도 별도의 읽기 모델을 만들거나 특수한 어셈블러를 제공하여 필수 DTO를 구축 할 수 있습니다. 좋아

, 이제 두 번째 포인트 :

당신이 도메인 엔티티는 데이터베이스 모델을 구축하는 것과 같은 방식으로 모델링하려고하는 것 같다. DDD에서는 먼저 비즈니스 요구 사항과 모델의 동작에 중점을 두어야합니다. 의미있는 도메인 모델을 구축 할 때 데이터 관계가 그다지 중요하지 않습니다 (조금 나중에 수정). 따라서 먼저 도메인 전문가로부터 비즈니스 사례 시나리오를 수집하는 데 집중해야합니다. 집계는 실제 비즈니스 불변성에 기반해야합니다. 팀 (비즈니스 구성원 포함)과 함께 공통 모델을 만들어야합니다. 몇 가지 지식을 정리 한 후에는 디자인이 완전히 달라질 가능성이 큽니다. 어쩌면 사람은 실제로 집합 적 루트가 아니라 값 개체 일뿐입니다. Population Membership 엔티티가 필요하지 않은 것 같습니까? 집합체의 가장 일반적인 디자인은 다중 값 객체가있는 단일 (루트) 엔티티입니다.그 외에도 - 나는 도메인 모델에 거의 관계없이 (ID 제외) 완전히 별도의 데이터베이스 모델을 생성합니다. 도메인 < -> dbmodel 사이를 변환하기 위해 변환 레이어 (매퍼 컴포넌트)를 사용합니다. 최근의 프로젝트에서 db 모델은 도메인 계층과 매우 다릅니다 (이는 지속성 계층의 요구에 맞게 조정되었습니다. 예를 들어 전체 개체가 아닌 단순한 프리미티브 값). 관계형 db의 경우에는 양방향 관계를 명시 적으로 제공 할 수도 있습니다 (실제로 orm을 사용할 필요조차 없습니다). db 모델을 도메인 모델과 분리 할 때 많은 이점이 있습니다. 디자인은 확실히 유연합니다. 그러나 db < -> 도메인 계층 간의 매핑 비용 (개발자 작업)은 간단한 프로젝트에서 너무 커질 수 있습니다. 그런 경우, 보통 공통 모델로 시작한 다음 리팩토링을 분리 가능한 레이어로 시작합니다.

아, 또 다른 중요한 점은 일반적으로 다른 집계 루트를 id로만 참조하는 것이 좋습니다. 이렇게하면 복잡한 객체 그래프에 문제가 없으며 단일 트랜잭션 내에서 다른 집계를 수정할 필요가 없습니다. 집계 루트는 다른 루트를 수정해서는 안됩니다. 집계 사이에서 통신해야하는 경우 대신 이벤트를 사용하십시오.

는 본이 버논에 의해 기사의 위대한 시리즈를 참조하십시오 :

http://dddcommunity.org/library/vernon_2011/

나는이 기사가 당신이 집계 모델링 개념을 이해하는 데 도움이 될 수 있습니다 생각합니다.