4

DDD のコンテキストでは、リポジトリは集約ルートのみを照会する必要があると常に言われています。集約ルートは、集約内の他のエンティティへのアクセスを提供します。しかし、集計内のエンティティへのクエリはどのようにモデル化されるのでしょうか?

Orders 集計の場合を考えてみます。注文はルートであり、詳細明細のリストを持ち、製品 (別の集計のルート) を参照し、数量などの他の属性を持ちます

ここで、特定の製品を参照する行を一覧表示または注文し、さまざまなサービスで使用されるレポートを生成する必要があるとします。たとえば、製品の注文で要求されたアイテムの平均数を計算します。

すべての Oder を検索してから、すべての Lines を一覧表示し、関心のあるものを選択するのは非現実的です。Orders リポジトリの getLinesByProduct() の方が便利に思えますが、Aggregate から Lines を公開します。

このクエリをモデル化するにはどうすればよいですか?

おそらく問題は、コマンド モデルをクエリしていて、詳細行が必要なすべての情報を含むエンティティである (非正規化された) クエリ モデルが必要なことです。

4

1 に答える 1

2

おそらく問題は、コマンド モデルをクエリしていて、詳細行が必要なすべての情報を含むエンティティである (非正規化された) クエリ モデルが必要なことです。

これはまさにそうです。DDD は、クエリの問題に対処することを意図したものではなく、さまざまな制約や ORM によって課せられる制約のために、摩擦を伴うことがよくあります。クエリ、特にレポートは個別に処理する必要があります。読み取りモデル パターンを使用して、コア アプリケーションの一部であるクエリをサポートしたり、レプリケートされたデータに基づいて動作する完全に別のレポート システムを使用したりできます。

于 2012-08-02T05:28:32.200 に答える