質問: 私は過去数日間DDDを学んでいて、集約ルートのいくつかのコアコンセプトを理解するのに苦労しています。たぶん誰かが私に正しい方向に押し込んで、このシナリオでのベストプラクティスを詳しく説明することができます: この例を簡単にするために、レストランと営業時間という2つのエンティティのドメインがあるとします。レストランは集約ルートとして定義されます。 !テキスト すべてのオンライン例で私が理解したことから(間違っている場合は訂正してください)、集約ルートは、インスタンスが必要になるたびにすべてのサブエンティティを積極的にロードしています。そのため、レストランでメソッドを呼び出す場合は常に、すべての営業時間が読み込まれます(使用されているかどうかに関係なく)。 この例では、そのレストランに新しい時間が追加されたときに、営業時間の交差がないことを確認したいと思います。この場合、既存の開始時間と比較する必要があるため、他のすべての開始時間の熱心なロードは理にかなっています。 しかし、これは一種の制限です。何か別のコレクション(レストランの画像など)を追加するたびにわかっているので、ほとんどのメソッドで1つのコレクションしか必要としない場合でも、SQLの負荷はますます重くなります。 私は2つの可能な解決策を考えることができます: **遅延読み込み** エンティティフレームワークのプロパティプロキシを介した遅延読み込み時間/サブエンティティ。したがって、集約ルートは、熱心にロードしなくても存在できますが、必要なときはいつでもアクセスできます。しかし、私が答えを探しているところはどこでも、集約ルートでの遅延読み込みは悪い習慣と見なされていることを知りました。たぶん誰かが理由を説明できるでしょう。 **より小さな集合根** もちろん、開店時間自体を集計ルートとして定義することもできますが、ビジネスロジック(この場合は交差の検証)をモデルの外に出す必要があります。 上記のすべての例では、コマンドサイドについてのみ説明しています(クエリやシリアル化ではありません)。 多分私はいくつかの基本的なアイデアを見逃している。この例では、集計ルートをどのように編成する必要がありますか?遅延読み込みが悪い習慣と見なされるのはなぜですか? **編集** 「意見に基づく」ためにこの質問が閉じられた理由が**わかり**ません。私はベストプラクティスと、なぜこの場合レイジーロードが行われないのかを尋ねています。
回答: > しかし、私が答えを探しているところはどこでも、集約ルートでの遅延読み込みは悪い習慣と見なされていることを知りました。 > > それは正確には当てはまりません。実際の制限は、直接参照により、集約ルートで*他の集約*を遅延ロード*する*ことです。代わりに、識別子を使用して他の集計を参照することをお勧めします。この制限には、その背後に非常に正当な理由があります。 集計を参照すると、アプリケーションのメモリフットプリントが不必要に増加します(トランザクションで使用されないエンティティを取得します)。ロックが有効になっている非常に同時使用の場合、アプリケーションのパフォーマンスが低下します(エンティティを不必要にロックする)。データの分割を妨げます(両方の集計を同じデータノードで処理する必要があります)。 各集約ルートは、独自の整合性境界を定義します。各トランザクションは、 *1つの集計の一貫性*を確保するための*もの*です。 *ドメインイベント*を介して通信される、アグリゲート全体の更新操作(またはトランザクション)は、 *最終的には整合性*があると*見なされ*ます。 別の集合体への直接参照を保持しているために遅延読み込みが必要であり、それらに対して更新を実行する場合は、設計を再考する必要があります。 シナリオの選択は、通常どおり、ビジネスコンテキストまたはそれが扱うドメインによって異なります。 *OpeninigTime*が独自の整合性境界を持つ独立した集計であると考える場合は、そのIDのみを保持し、適切な集計を取得することによって*OpeningTime*集計が処理するIDを含むドメインイベントを発行する必要があります。ただし、そうでない場合(可能性が高いと思われます)、参照を保持し、遅延読み込みを行い、それに対して更新を実行できます。