2

私はDDDで遊んでいますが、この質問がポップアップします。子の集約ルートをロードするにはどうすればよいですか? いくつかのパフォーマンスの問題が発生します。次の例を想像してください。

public AggregateRoot1
{
     #region
        properties
     #endregion

     public AggregateRoot2 AR2{get;set;}

     public IEnumerable<AggregateRoot3> AR3List{get;set;}

     (...)
}

AggregateRoot1 を取得するときに AggregateRoot2 と AggregateRoot3 のリストをロードすると、グラフが巨大になります。これは良いアプローチとは思えません。

2 つのオプションがあります。

  1. AggregateRoot2 AR2をGuid AR2Idに置き換え、IEnumerable AggregateRoot3> AR3ListをIEnumerable Guid> AR3ListIdsに置き換えます。すべての AR 参照は、ID で置き換える必要があります。
  2. 私は IEnumerable ARListIds アプローチが好きではないので、0...* AR への参照を削除することを考えています。AR のリスト データを必要とするすべての操作は、David Masters sugest hereのようなドメイン サービスを介して行う必要があります。

ところで、遅延読み込みの使用は考えていません。

子ARの読み込みについてご意見をお待ちしております。ありがとう

4

2 に答える 2

7

理想的には、アグリゲート間の参照はIDのみによるものである必要があります。これはオプション1です。ただし、各参照を評価して、参照保持集計の整合性に必要かどうかを確認する必要があります。2つのアグリゲート間の関係自体をアグリゲートにして、個別にロードできる場合があります。全体として、骨材を設計する際のさまざまなトレードオフの詳細な分析については、VaughnVernonによる効果的な骨材設計をご覧ください。これは、DavidMastersがリンクされた質問で指摘していることでもあります。

于 2013-03-13T15:55:31.590 に答える
0

グラフが大きくなりすぎて遅延読み込みを使用できない場合は、モデルが何らかの作業を使用できる可能性があることを示している可能性があります。エンティティが適切に独自の集約ルートである可能性があります。

ファクトリとリポジトリを使用すると、大きなオブジェクトをより適切に管理できます。大きなオブジェクトをキャッシュしたり、AggregateRoot1 のファクトリ内にシングルトン パターンを実装したりできます。

DDD に従う理由の 1 つは、複雑さのカプセル化です。しかし、非ルート オブジェクトの ID を持つと、このカプセル化が壊れます。パフォーマンスに関する考慮事項はありますが、パフォーマンスのためにコードを時期尚早に最適化しても、優れたソフトウェアが作成されるとは限りません。

于 2013-03-13T21:51:39.047 に答える