6
DDD集計はWebアプリケーションで本当に良いアイデアですか？
私はドメイン駆動設計に飛び込み、私が出会う概念のいくつかは表面的にはかなり理にかなっていますが、それらについてもっと考えるとき、それは本当に良いアイデアかどうか疑問に思う必要があります。 たとえば、集計の概念は理にかなっています。ドメインモデル全体を扱う必要がないように、所有権の小さなドメインを作成します。 ただし、これをWebアプリのコンテキストで考えると、データベースに頻繁にアクセスして、データの小さなサブセットを取り戻します。たとえば、ページには注文の数だけがリストされ、クリックして注文を開いて注文IDを表示するリンクが表示されます。 私は右の理解集約だ場合、私は一般的にメンバーが含まれますOrderAggregateを返すために、リポジトリのパターンを使用することになりGetAll、GetByID、Delete、とSave。いいですね。しかし... GetAllを呼び出してすべての注文を一覧表示すると、このパターンでは、集計情報の一覧全体、注文全体、注文明細などが返される必要があるように思えます。その情報の小さなサブセットのみが必要な場合（ヘッダー情報のみ）。 何か不足していますか？または、ここで使用する最適化のレベルがありますか？必要のないときに情報の集合体全体を返すことを支持する人がいるとは想像できません。 確かに、リポジトリのようなメソッドを作成できGetOrderHeadersますが、そもそもリポジトリのようなパターンを使用する目的に反しているようです。 誰も私のためにこれを明確にすることはできますか？ 編集： さらに調査を重ねた結果、ここでの断絶は、純粋なリポジトリパターンが、ほとんどの人がリポジトリと考えているものと異なることだと思います。 Fowlerは、リポジトリをコレクションセマンティクスを使用するデータストアとして定義し、通常はメモリ内に保持されます。これは、オブジェクトグラフ全体を作成することを意味します。 Evansはリポジトリを変更して集約ルートを含めるため、リポジトリは切断され、集約内のオブジェクトのみをサポートします。 ほとんどの人は、リポジトリを栄光に満ちたデータアクセスオブジェクトと考えているようです。ここでは、必要なデータを取得するメソッドを作成するだけです。これは、ファウラーの「エンタープライズアプリケーションアーキテクチャのパターン」で説明されているような意図ではないようです。 さらに、リポジトリは、主にテストとモック作成を簡単にするため、または永続性をシステムの残りの部分から切り離すために使用される単純な抽象化と考えています。 答えは、これが最初に思っていたよりもはるかに複雑な概念であると思います。