6

私はDDDについて学び始めており、永続性からエンティティオブジェクトを取得し、UIのビューモデルでそれらを再構築することのパフォーマンスへの影響について懸念しています。

私が2つの集約ルートを持っているとしましょう：

Person      Orders
------      -------
personId    orderId
name        personId

各アグリゲートルートには、アグリゲート全体の基本的なCRUD操作を担当する独自のリポジトリがあります。

UIに次の列が必要だとします。

viewmodel
---------
personName
numberOfOrders

このビューモデルにデータを入力する方法は2つ考えられます。

  1. すべてのpersonエンティティを熱心にロードし、personIdに基づいてすべての注文を熱心にロードし、ロードされたエンティティをビューモデルに再構築します。
  2. JOIN / COUNT（orderId）ストアドプロシージャを作成し、データベースがビューモデルと同じ構造でデータを返すようにします。

明らかに、オプション1は、複数の人と複数の注文があり、複数のデータベース呼び出しが発生する可能性があるため、非常にコストのかかる操作になる可能性があります。オプション2では、データベース呼び出しが1回だけ必要です。

オプション2が優先（パフォーマンス）オプションである場合、この「ビューモデル」といわゆる「データベース呼び出し」をどこに保存しますか？実装できるリポジトリの上に別の「データサービス層」がありますか？それとも、DDDが一般的にどのように実装されるかに関するアンチパターンですか？

基本的に、パフォーマンスを念頭に置いて、複雑なDDD集計をカスタムUIビューモデルと調整するにはどうすればよいですか？

更新

仕様/クエリオブジェクト

友人との話し合いの中で、彼は考えられる解決策はある種の仕様/クエリオブジェクトパターンであると提案しました。唯一の問題は、これをリポジトリレベルで実装する必要があり、PersonsとOrdersを1つの大きな集合体に結合する必要があることです。これは、トランザクションの一貫性の理由から一般的に避けているものです。

4

2 に答える 2

6

特定の人物の統計を返す専用の値オブジェクトとリポジトリを導入できます。

// value object
class PersonStatistics {
    String PersonName
    Int NumberOfOrders
    Money AverageOrderAmount
}

// repository
interface PersonStatisticsProvider {
    PersonStatistics Get();
}

これは、読み取りモデルパターンに似ています。

于 2012-08-21T17:32:51.907 に答える