DDD : 루트 집계가 다른 루트 집계에 대한 참조를 보유하는 것이 맞습니까?

도메인 기반 디자인 (DDD)을 따를 때 루트 집계가 별도의 집계에서 루트 엔티티가되는 내부 엔티티에 대한 참조를 보유하는 것이 맞습니까?

나는 이것이 파란색 책 에 대한 이 규칙으로 인해 올바르지 않다고 생각합니다 .

AGGREGATE 경계 외부의 어떤 것도 루트 ENTITY를 제외하고 내부의 모든 것에 대한 참조를 보유 할 수 없습니다. 루트 ENTITY는 내부 ENTITIES에 대한 참조를 다른 개체에 전달할 수 있지만 해당 개체는 일시적으로 만 사용할 수 있으며 참조를 유지할 수 없습니다. 루트는 VALUE OBJECT의 사본을 다른 오브젝트에 전달할 수 있으며, VALUE 일 뿐이고 더 이상 AGGREGATE와 연관되지 않기 때문에 어떤 일이 발생해도 상관 없습니다.

루트 집계가 다른 루트 집계에 대한 참조를 보유하는 경우 전자의 경계가 위반되고 집계의 전체 개념이 손상되므로 루트 집계가 다른 루트 집계에 대한 참조를 보유해야 할 필요가 있다고 생각되면 다른 엔티티 를 만들려면 다른 루트 엔티티와 동일한 멤버 중 일부를 공유하지만이 책의 다른 규칙에 따라 글로벌 ID는 없습니다.

루트 단체는 글로벌 정체성을 가지고 있습니다. 경계 내부의 엔티티는 AGGREGATE 내에서만 고유 한 로컬 ID를 갖습니다.

나는 이것이 올바른 길이라고 생각하지만 반복적이고 중복 적이라고 느끼기 때문에 (순수한 OOP와 함께 DDD의 맥락에서 벗어 났을 때) 나는 약간의 피드백을 요구하고 있습니다.

책을 과도하게 해석했을 수 있습니다. 기본적으로 말합니다 : 집계 외부의 어떤 것도 루트를 제외한 내부의 어떤 것에 대한 참조를 가질 수 없습니다. 따라서 루트에 대한 참조를 보유하는 것이 합법적입니다. 루트에 대한 참조를 보유한다고해서 그것이 자신의 집계의 일부이고 그 불변량을 제어 할 수 있다는 것을 의미하지는 않습니다. 그것은 자신의 불변성과 자율성을 유지합니다.

하나,

• 일반적으로 허용되는 모범 사례 는 전체 참조가 아닌 ID를 저장하여 AR을 참조하는 것입니다.
• 골재 설계에 대한보다 현대적인 접근 방식 ( Red Book 참조 )은 골재 간 명확한 분리를 옹호합니다. 비즈니스 트랜잭션은 단일 집계의 상태 만 변경해야합니다. 이 가정 하에서 동시에 두 개의 집계를 수정하지 않기 때문에 다른 집계에 대한 참조를 저장할 필요가 사라지는 경향이 있습니다.

루트 집계가 별도의 집계에서 루트 엔티티가되는 내부 엔티티에 대한 참조를 보유하는 것이 맞습니까?

이런 일은 절대 일어나지 않습니다. 값 개체는 여러 집계의 일부일 수 있지만 엔터티는 아닙니다. 그 이유는 집계간에 동일한 엔터티 인스턴스 를 공유 할 수있는 요소가 없기 때문입니다 . 엔터티 인스턴스 E가 집계 인스턴스 A와 B에 속한다고 가정 해 봅시다. DDD의 전제는 집계가 진입 점이라는 것을 전제로 A를로드하고이를 통해 엔터티 E를 수정할 수 있습니다. B (로드하지 않은).

여기에서 Greg Young의 답변을 참조하십시오 : http://domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html

집합 루트 개체는 일반적으로 도메인의 일부인 속성 만 가져야합니다.

집계에없는 속성을 가진 AR 객체가 있으면 즉시 질문에 직면하게됩니다. '왜 안돼?'

다른 객체의 ID를 추가 할 수 있습니까? 아니면 저장소를 주입?

그러나 루트 객체를 모두 참조하고 필요한 논리를 수행하는 크로스 도메인 서비스를 추가 해야하는 것처럼 들립니다.