domain-driven-design - DDD で「不完全な」集計を使用することはできますか?

Question

DDD は、集約ルートを介してのみエンティティにアクセスする必要があると述べています。たとえば、多くの子 Y エンティティを持つ可能性のある集約ルート X があるとします。ここで、いくつかのシナリオでは、一度にこれらの Y エンティティのサブセットのみを本当に気にします (おそらく、それらをページ付きリストなどに表示しています)。

その場合、そのようなシナリオで不完全な集計を返すようにリポジトリを実装しても問題ないでしょうか? すなわち。Ys コレクションである X オブジェクトには、関心のある Y インスタンスのみが含まれ、すべてではありませんか? これにより、たとえば、Y を含む何らかの計算を実行する X のメソッドが期待どおりに動作しない可能性があります。

これはおそらく、問題の Y エンティティが集約ルートに昇格されたと見なされるべきであることを示しているのでしょうか?

私の現在のアイデア (C#) は、LINQ の遅延実行を利用して、X オブジェクトが Y との関係を表す IQueryable を持つようにすることです。このようにして、フィルタリングを使用して透過的な遅延読み込みを行うことができます... ORM（私の場合はLinq to Sql）を使用するのは少し難しいかもしれません。

他に賢いアイデアはありますか？

Answer 1

多くの子エンティティを持つ集約ルートは、コードの匂い、または DDD の匂いだと考えています。:-) 一般的に、私は 2 つのオプションを検討します。

1. アグリゲートを多数の小さなアグリゲートに分割します。これは、元の設計が最適ではなかったことを意味し、いくつかの新しいエンティティを特定する必要があります。
2. ドメインを複数の境界付けられたコンテキストに分割します。これは、集約内のエンティティの共通のサブセットを使用するシナリオの特定のセットがある一方で、別のサブセットを使用するシナリオの他のセットがあることを意味します。

Answer 2

ジミー・ニルソンは彼の本の中で、完全な骨材を読む代わりに、その一部のスナップショットを読むことができるとほのめかしています。ただし、スナップショットクラスの変更をデータベースに保存することはできません。

ジミーニルソンの本第6章：インフラストラクチャの準備-クエリ。ページ226。

スナップショットパターン

Answer 3

あなたは本当に2つの重複する質問をしています。

1. あなたの質問のタイトルと前半は哲学的/理論的です。「集約ルート」のみを介してエンティティにアクセスする理由は、説明している種類の実装の詳細を抽象化するためだと思います。集約ルートを介したアクセスは、信頼できるアクセス ポイントを持つことで複雑さを軽減する方法です。慣習に従うことで、摩擦/あいまいさ/不確実性を排除しています。ルート内でどのように実装されているかは関係ありません。エンティティを要求するとそこに存在することがわかっているだけです。あなたが説明したように、この観点が「フィルタリングされたリポジトリ」を除外するとは思いません。しかし、成功の落とし穴を提供するために開発者が陥る可能性があるのは、リポジトリの「フィルタリング」について明示せずにリポジトリをインスタンス化することは不可能であるべきです。同様に、リポジトリ インスタンスへの共有アクセスが可能な場合は、呼び出し元でコーディングするときに「フィルター処理された状態」を明示する必要があります。

2. 質問の後半は、特定のプラットフォームでの実装に関するものです。実行の遅延について言及している理由がわかりませんが、それはフィルタリングの質問とは正反対だと思います。フィルタリング自体は、LINQ で実装するのが少し難しいかもしれません。Where ラムダをインライン化するのではなく、それらのコレクションを設定し、必要なフィルターに応じて 1 つを選択します。

Answer 4

コードはとにかくコンパイルされるので許可されますが、純粋な DDD 設計を行う場合は、オブジェクトのインスタンスが不完全であってはなりません。

子エンティティのごく一部のみを使用する巨大なオブジェクトをロードするのが怖い場合は、LazyLoading を検討する必要があります。

LazyLoading は、アクセスされる瞬間まで、遅延読み込みすることに決めたものの読み込みを遅らせます。コードがコールバックを呼び出すと、コールバックを使用してローディング メソッドを呼び出します。