DDD：ルートアグリゲートが別のルートアグリゲートへの参照を保持することは正しいですか？
ドメイン駆動型設計（DDD）に従う場合、ルートアグリゲートが、たまたま別のアグリゲートのルートエンティティである内部エンティティへの参照を保持することは正しいですか？
私はこれが正しくないことを信じています、主に ブルーブック に関するこのルールが原因です：
AGGREGATE境界の外側には、ルートENTITYを除き、内側への参照を保持できません。ルートENTITYは内部ENTITIESへの参照を他のオブジェクトに渡すことができますが、それらのオブジェクトは一時的にしか使用できず、参照を保持できない場合があります。ルートはVALUE OBJECTのコピーを別のオブジェクトに渡すことができます。これは単なるVALUEであり、AGGREGATEとの関連付けがなくなるため、何が発生しても問題ありません。
ルートアグリゲートが別のルートアグリゲートへの参照を保持している場合、前者の境界に違反し、アグリゲートの概念全体が破損しているため、ルートアグリゲートが別のルートアグリゲートへの参照を保持する必要があるように見える場合は、 differentエンティティを作成します。これは、おそらく他のルートエンティティと同じメンバーの一部を共有しますが、この他のグローバルアイデンティティはありません本のルールは次のように述べています：
ルートエンティティはグローバルなアイデンティティを持っています。境界内のエンティティはローカルIDを持ち、AGGREGATE内でのみ一意です。
これは正しい方法だと思いますが、反復的で冗長な感じがするので（DDDのコンテキストから外れたときに、純粋なOOPで）、いくつかのフィードバックを求めています。
あなたはその本を解釈し過ぎているかもしれません。それは基本的に言う：Aggregateの外の何かはルートを除いて内部の何かへの参照を保持できません。したがって、ルートへの参照を保持することは合法です。ルートへの参照を保持することは、それが独自の集計の一部であり、その不変条件を制御できることを意味しません。独自の不変条件と自律性を維持します。
しかしながら、
- 一般的に受け入れられている グッドプラクティス は、完全な参照ではなく、IDを格納してARを参照することです。
- 集計デザインへのより最近のアプローチ（ Red Book を参照）は、集計間のより明確な分離を提唱しています。ビジネストランザクションは、単一の集約の状態のみを変更する必要があります。この仮定の下では、2つの集計を同時に変更することはないため、別の集計への参照を格納する必要はなくなりがちです。
ルート集約が、たまたま別の集約のルートエンティティである内部エンティティへの参照を保持することは正しいですか？
これは決して起こりません。値オブジェクトは、エンティティではなく、複数の集合体の一部になることができます。その理由は、アグリゲート間で同じエンティティインスタンスを共有することを妨げるものがないためです。エンティティインスタンスEが集約インスタンスAとBの両方に属しているとしましょう。DDDの前提は集約がエントリポイントであることなので、Aをロードし、エンティティEを変更できます。 B（ロードしなかった）。
ここでグレッグ・ヤングからの回答をご覧ください： http://domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html
集約ルートオブジェクトには、（通常）ドメインの一部であるプロパティのみを含める必要があります。
集計にないプロパティを持つARオブジェクトがある場合は、すぐに問題に直面します。 '何故なの？'
他のオブジェクトのIDを追加できますか？またはリポジトリを注入しますか？
しかし、両方のルートオブジェクトを参照し、必要なロジックを実行するクロスドメインサービスを追加する必要があるようです