DDD - 検索用に高パフォーマンスのリポジトリを実装する方法

Question

DDD とリポジトリ パターンについて質問があります。

Customer 集約ルートの Customer リポジトリがあるとします。Get メソッドと Find メソッドは、アドレスなどのオブジェクトを含む、完全に設定された集計を返します。大丈夫です。しかし、ユーザーが UI で顧客を検索しているときは、集計の「概要」、つまり要約された情報を含むフラットなオブジェクトだけが必要です。

これに対処する 1 つの方法は、通常どおりリポジトリで find メソッドを呼び出し、アプリケーション層で各顧客の集計を CustomerSearchResult / CustomerInfo DTO にマップし、それらをクライアントに送り返すことです。

しかし、これに関する私の問題はパフォーマンスです。各顧客集計では、すべての関連付けを設定するために複数のクエリが必要になる場合があります。したがって、検索条件が 50 人の顧客に一致した場合、DB 上でかなりのヒットとなり、必要のないデータが取得される可能性があります。

もう 1 つの問題は、顧客の集計ルート境界の外側にある顧客に関する要約データ (たとえば、最後の注文の日付など) を含めたい場合があることです。Order には独自の集計があるため、顧客の注文情報を取得するには OrderRepository を呼び出す必要があり、これもパフォーマンスを低下させます。

したがって、今私には 2 つの選択肢が残されていると思います。

1. CustomerRepository に追加の Find メソッドを追加します。このメソッドは、1 つの効率的なクエリを実行することでこれらのサマリー オブジェクトのリストを返します。

2. 1 で説明した find メソッドだけを備えた専用の読み取り専用 CustomerInfoRepository を作成します。

しかし、これらは両方とも DDD の原則に反しているように感じます。私のリポジトリは汎用ベースから継承しています。リポジトリ ここで T :IAggregateRoot。これらの概要情報オブジェクトは集計ではなく、T とは異なるタイプであるため、実際には #1 は設計に反しています。

おそらく #2 では、IAggregateRoot 制約を使用せずに抽象 SearchRepository を作成するでしょうか?

私のドメインにも同様のシナリオがたくさんあります。

このシナリオをどのように実装しますか?

ありがとう、 デイブ

アップデート

Theo の回答を読んだ後、オプション #2 を選択し、これらのシナリオに合わせてインフラストラクチャ内に特化した SearchRepository を作成すると思います。その後、アプリケーション層 (WCF サービス) は、ドメイン エンティティを DTO にマッピングするのではなく、サマリー DTO を直接設定するだけのこれらのリポジトリを呼び出すことができます。

**** アップデート 2 ****

これは 1 年以上前に質問したものですが、その後、まさにこの問題を解決することを目的とした CQRS を発見したことだけ付け加えておこうと思いました。ウディ・ダハン (http://www.ウディダハン.com/) とグレッグ・ヤング (http://codebetter.com/gregyung/）それについてはたくさん書いています。DDD を使用して分散アプリケーションを作成している場合は、CQRS が最適です。

Answer 1

要約した情報だけを表示したいと思います。これらの要約情報は、ドメイン モデルのエンティティや値オブジェクトではありません。それらは単なる情報であり、それ以上のものではありません。

レポート情報を表示するようなものです。そのようなことに対処する場合、私は純粋な DDD アプローチには固執しないでしょう。提案されたオプションは問題ありません。これで仕事は完了します。DDD を定説として扱ってはいけません。枠にとらわれずに考えてみましょう。DDDを少し緩めます。

ただし、表示目的でモデルの外に情報値を作成しているだけであることに注意してください。そのため、ユーザーが 1 ビットの情報を選択して、その情報 (ドメイン モデルで定義されている) で何らかの操作を行う場合、情報値から識別子を抽出し、リポジトリからエンティティ/値オブジェクト/集合体を取り出す必要があります。

このビデオを強くお勧めします。 エリック・エヴァンス：この本以来、DDD について学んだこと. 。彼の本を読んだ場合は、ビデオ全体を実際に見る必要があります。30:00 あたりで、Eric Evans 自身が集計について話し、現在抱えている問題について言及している箇所に非常に注目してください。

Answer 2

私は...するだろう：

1. 表示用のオブジェクトのビューを表す別のオブジェクトを返します。顧客情報。
2. DataTable を返します。多くの場合、汎用コンテナーが最も簡単で最良の方法です。

汎用ベース リポジトリの T が Customer である場合、集約ルートの概念を誤って適用していると思いますが、私は厳密ではありません。 伝道者. 。私は、顧客データのビューである DataTable や読み取り専用オブジェクトなど、顧客と論理的または快適にグループ化するデータを返す顧客用のリポジトリを設計します。