ドメイン駆動型設計における集約ルートの複雑さ

集約の複雑さにはどこの線を引いていますか？明確にするために、私の集計にObjectCのリストを持つObjectBのリストを持つObjectAのリストがある場合、集計はObjectCの取得を担当するべきですか？または、この複雑さを階層の2つのレベルに保つために別の集約を作成することを検討する必要がありますか？ドメイン駆動型設計における集約ルートの複雑さ

出典

2011-05-31 Sergey Akopov

ほとんどの場合、集計の境界は、モデルに必要な整合性境界にする必要があります。つまり、ObjectAまたはBまたはCへの変更が、おそらく同じ集約に属しているよりも、互いに一致する必要がある場合です。

複雑さ（ビジネスロジックの複雑さ）は、ドメイン内のすべての概念を特定し、関連するエンティティ/ VO間で動作を分割することによって処理する必要があります。

オブジェクトの取得の複雑さ（インフラストラクチャの複雑さ）は、インフラストラクチャで処理する必要がありますが、集約では処理しないでください。

結論として、あなたのドメインと一貫性の境界に沿ってARをモデル化し、インフラストラクチャの懸念を緩和しないようにします。

出典

2011-05-31 07:41:05

ありがとうございます！だから、私は、オブジェクトの取得方法がインフラストラクチャの関心事であると考えています。しかし、どのエンティティがARであるべきかを判断する上で必要ではないでしょうか？場合によっては、ObjectA集約ルートからObjectBにアクセスすることは論理的ですが、別のコンテキスト/ユースケースでは、ObjectBはそれ自体の集約ルートである可能性があります。結局のところ、インフラストラクチャの懸念は決定的な要因にはならないだろうか？ –

インフラストラクチャの懸念がAR境界を指示するべきではありません。あなたの一貫性の要件が必要です。アイデアは、あなたのドメイン内のコンセプトが、一つのバウンディングコンテクストのARと、別のバウンディングコンテクストのエンティティになることです。エンティティにアクセスすると、不変量と一貫性を強制するために、アグリゲートを持つという穴の目的を直接破ります。私はあなたが[Eric Evans video]（http://www.infoq.com/presentations/ddd-eric-evans）を見て、それからDDDブックからBounding Contextsの章を再読みとることをお勧めします。あなたのユースケースは、BCを決定するための良いスタートです –

Lulianのように、私はあなたのARがどのように見えるべきかというルールはないと言います。 ObjectA、B、CのARが同じビジネスコンテキストに属している場合は、その罰金があります。しかし、クライアント/ユースケースがどのようにあなたのモデルを使用しているかを反映させるべきだと思います。 ObjectCを常に必要とし、オブジェクトグラフをObjectAとBからCへとトラバースすることが不要なトラバーサルのように感じる場合は、モデルが正しくない可能性があります。

ルートオブジェクトがObjectAであり、ObjectARepositoryを持っている場合は、GetObjectCsByObjectA（ObjectA objectA）のようなリポジトリメソッドを追加して、すべてのCをAにリストすることができます。 ObjectCが複数のObjectB

あなたのGUI /クライアントがこのARをどのように使っているのか（自分自身を繰り返す...） Linqフィルタを追加する拡張メソッドを追加するか、 AからCへのトラバースを容易にするために検索します。お気に入りではありませんが、動作します。 ObjectAのObjectBのコレクションを、値オブジェクトまたは永続化されていない単純なリストラッパークラスでラップしようとすると、このコレクションにアクセスするときに作成するだけです。このラッパーは、GUIに合った必要なアクセス方法と、リスト項目の追加、置換、削除時の検証を提供することができます。ラッパーはクライアントのためのショートカットになるので、ARがAR内にどのように構築されているか気にする必要はありません。

ObjectBとObjectCは、このAR以外の他のエンティティとの関連付けをしていますか？

出典

2011-06-01 13:02:43

あなたはそうです、回答を読んだ後、それは完全に文脈上のルールです。私は、ARを決定することは、ドメインの境界に結合されるだけでなく、ユースケースとも関係するプロセスであることに同意する必要があります。ユースケースを見ることなく、自分の集約内のオブジェクトが単独で集約できるかどうかを、どうやって知っているのか分かりません。あなたの最後の質問に答えるために、はい、ObjectCはARの外に他の関連を持っています。 –

一般的なガイドラインは、AR内のすべての子オブジェクトは、AR境界外の関連付けを持つべきではないということです。どうして？ルートインスタンスを削除/削除する場合は、すべてのAR子オブジェクトも削除する必要があります。これは、子が外部の関連付けを持つObjectCに似ていると、操作が面倒になる可能性があります。多分あなたは独自のリポジトリを持つARとしてObjectCをアップグレードする必要がありますか？子エンティティは、他のAR内の自己ARでも構いません。 –

"親/子"はあいまいな場合があります。 Evansモデルに従えば、AR *はARと他のARのメンバーの両方になることはできません。 2つのARには関係があります。外部オブジェクトはARのみを参照できますが、ARのエンティティは外部参照を保持できます。 ObjectAのObjectCのリストは、集約メンバーシップを付与しません。 ObjectCが本当にARであれば、それはAR-AR関係です。 ObjectCが本当にObjectA ARの一部である場合、ObjectCはARであることもできません。 ObjectAのみからのObjectCへの参照の存在は、2つの可能性を区別するのに十分ではありません。 ARは概念的であり、コードによってのみ表現することはできません。 – Sisyphus

ドメイン駆動型設計における集約ルートの複雑さ

答えて

関連する問題