集合体の複雑さの線引きはどこにあるのでしょうか? 明確にするために、集計に ObjectC のリストを持つ ObjectB のリストを持つ ObjectA のリストがある場合、集計は ObjectC の取得を担当する必要がありますか? それとも、この複雑さを階層内のいくつかのレベルに抑えるために、別の集計を作成することを検討する必要がありますか?
2 に答える
7
ほとんどの場合、Aggregate の境界は、モデルに必要な一貫性の境界でなければなりません。これは、ObjectA、B、または C への変更が互いに一貫している必要がある場合、それらはおそらく同じ集合体に属していることを意味します。
複雑さ (ビジネス ロジックの複雑さ) は、ドメイン内のすべての概念を特定し、関連するエンティティ/VO 間で動作を分割することによって処理する必要があります。
オブジェクト取得の複雑さ (インフラストラクチャの複雑さ) は、集約ではなくインフラストラクチャによって処理される必要があります。
結論モデルでは、ドメインと一貫性の境界に従って AR を設定し、インフラストラクチャの懸念を助長することはありません。
于 2011-05-31T07:41:05.930 に答える
1
lulian が言うように、AR がどのように見えるべきかを示すルールはないと思います。ObjectA、B、および C を使用した AR が同じビジネス コンテキストに属している場合は問題ありません。ただし、クライアント/ユースケースがモデルをどのように使用しているかについても検討する必要があると思います。常に ObjectC が必要であり、ObjectA および B から C までのオブジェクト グラフのトラバーサルが不必要なトラバーサルのように感じられる場合は、モデルが正しくない可能性があります。
ルート オブジェクトが ObjectA で、ObjectARepository がある場合は、A のすべての C を一覧表示する GetObjectCsByObjectA(ObjectA objectA) などのリポジトリ メソッドをいつでも追加できます。 1 つの A に対してすべての C を取得するため、1 になります。
最も重要なのは、GUI/クライアントがこの AR をどのように使用するかです (繰り返します...) Linq フィルターまたは検索を追加するための拡張メソッドを追加して、A から C へのトラバーサルを容易にすることができます。私のお気に入りではありませんが、機能します。ObjectB のコレクションを ObjectA でラップすることをお勧めします。このコレクションにアクセスするときに、値オブジェクトまたは永続化されずに作成される単純なリストラッパー クラスのいずれかを使用することをお勧めします。このラッパーは、GUI に適した必要なアクセス メソッドを提供し、リスト アイテムを追加、置換、および削除する際の検証も提供します。ラッパーはクライアントのショートカットになるため、AR が AR 内でどのように構築されるかを気にする必要はありません。
ObjectB と ObjectC には、この AR 外の他のエンティティとの関連付けがありますか?
于 2011-06-01T13:02:43.620 に答える