問題タブ [aggregateroot]

私は過去 2 週間にわたって DDD を研究してきましたが、特に印象に残ったことの 1 つは、集約ルートに他の集約ルートを含める方法でした。集約ルートはリポジトリから取得されますが、ルートに別のルートが含まれている場合、リポジトリには他のリポジトリへの参照があり、サブルートを構築するように求めていますか?

私が理解しているように、ドメインモデルはデータ（集合体ルート）のみを記述するクラスです。それらはPOCOであり、外部のライブラリを参照しません（特別なことは何もありません）。

一方、ビューモデルは、ドメインモデルオブジェクトと、のようなすべてのインターフェイス固有のオブジェクトを含むクラスですSelectList。ViewModelにはが含まれusing System.Web.Mvc;ます。

リポジトリはデータベースからデータを引き出し、ドメインモデルオブジェクトを介してデータを提供します。 どのメカニックまたはデバイスがビューモデルオブジェクトを作成し、データベースからそれらを作成しますか？ データベースにアクセスできる工場でしょうか？System.Web.Mvcなどのビュー固有のクラスをリポジトリにブリードしますか？他に何かありますか？

たとえば、都市のドロップダウンリストがある場合は、ビューモデルオブジェクトのルートで、DomainModel参照のすぐ隣にあるSelectListオブジェクトを参照します。

都市はデータベースから取得され、選択リストオブジェクトの形式である必要があります。個別の都市だけを抽出するための特別なRepositoryメソッドを作成せずに、適切なデータ型を使用できるように、冗長な2番目のSelectListオブジェクトのみを作成することをお勧めします。

典型的なOrderとOrderItemの例を考えてみましょう。OrderItemがOrder Aggregateの一部であると仮定すると、Orderを介してのみ追加できます。したがって、新しいOrderItemをOrder に追加するには、Repository を介して Aggregate 全体をロードし、新しいアイテムをOrderオブジェクトに追加して、Aggregate 全体を再度永続化する必要があります。

これには多くのオーバーヘッドがあるようです。Orderに 10 個のOrderItemsがある場合はどうなるでしょうか。このように、新しいOrderItemを追加するだけで、 10 個のOrderItemを読み取る必要があるだけでなく、これら 10 個のOrderItemをすべて再度挿入する必要があります。(これは、Jimmy Nillson が彼の DDD の本で採用したアプローチです。Aggregate を永続化するたびに、彼はすべての子オブジェクトをクリアしてから、再度挿入します。これにより、子の ID が変更されるため、他の問題が発生する可能性があります。データベースの IDENTITY 列のために毎回変更されます。)

Unit of Work パターンを Aggregate Root に適用して、何が変更されたかを追跡し、それらの変更のみをコミットすることを提案する人もいると思います。しかし、永続化ロジックがドメイン モデルに漏れているため、これは永続化無視 (PI) の原則に違反しています。

誰もこれについて前に考えたことがありますか？

モッシュ

どの要素にも含まれていないルート オブジェクトのリストを追跡したいと考えています。次の疑似コードが機能するようにします。

これにより、item1 と item2 が自動的に挿入され、item3 と item3 が削除され、item5 が更新されます (つまり、すべてのアイテムに対して session.SaveOrUpdate() を個別に呼び出したくありません)。

テーブルに関連付けられていない疑似エンティティを定義することはできますか? たとえば、Favorites クラスを定義し、その 2 つのコレクション プロパティをマップして、次のようなコードを書きたいとします。

FavoriteColors と FavoriteMovies は、Favorites クラスの唯一のプロパティで、IList と IList 型です。これら 2 つのコレクション プロパティのみを保持し、Favorites クラスは保持したくありません。

実際には、追加と削除を追跡し、親エンティティに属さず、それ自体を表す IPersistentCollection オブジェクトが必要です (エンティティのコレクション プロパティに発生するのと同じことが、親エンティティがない場合のみです)。コレクションがエンティティに属している場合、これは完全に機能し、その場合、2 つのセッション間でアイテムを追加および削除できます。

どんな助けでも大歓迎です。

ドメイン駆動設計について少し読んでみると、集約ルートからのトラバーサルによって集約内のすべてのエンティティにアクセスすることになっているようです。

ただし、同時に、プロパティ/フィールドが保護または非公開になるように、データを実際にカプセル化する必要があります。

したがって、私の質問は次のとおりです。フィールドが保護/非公開の場合、集計をどのようにトラバースすることになっていますか?

現時点で設定した方法は次のとおりです。ドメインモデルのすべてのプロパティを内部としてマークし、「設定」のメソッドを保護としてマークします。このように、少なくともモデルの外部からプロパティにアクセスすることはできませんが、モデル内のオブジェクトは他のオブジェクトのプロパティにアクセスでき、オブジェクト自体からのプロパティの設定のみを許可します。

私がこれを行ったとしても、これは他の集約エンティティのプロパティにのみ適用されるべきであるように感じます (つまり、顧客の「名前」は非公開のままですが、顧客の「注文」は内部としてマークする必要があります。 Customer -> Orders -> などからのトラバーサル)

これに関するガイダンスはありますか？

編集：

質問のより具体的な例を挙げてみましょう。オブジェクト グラフには、Bookshelf と Book という 2 つのオブジェクトがあります。この例では、Bookshelf が集約ルートであり、Books が Bookshelf に格納されているため、集約内のエンティティであるとします (Bookshelf には書籍のコレクションがあります)。

本棚に新しい本を追加するメソッドを書きたいと思います。DDD のベスト プラクティスに従って、Bookshelf クラスに AddBook(Book book) などのメソッドを記述する必要があると思います。

ただし、同じタイトルの本を本棚に追加できないというビジネス要件がある場合はどうなるでしょうか。Bookshelf.AddBook メソッド内に、書籍のコレクションをチェックして、この書籍がまだ存在していないことを確認するロジックが必要です。

問題は、Book オブジェクトを適切にカプセル化された方法で作成し、その "Name" プロパティにパブリックにアクセスできないため、それができないことです。

これはかなり不自然な例であることは理解していますが、問題をよりよく示していることを願っています。また、これは単なる DDD の問題ではなく、実際には OO カプセル化の問題であることにも気付きました。私がやろうとしていることを解決するための非常に一般的で簡単な方法があるに違いないと確信していますが、私はそれを非常に考えすぎています。

2 つの集計境界が互いに矛盾する複雑なシナリオがあります。

リクエストとミッションの 2 つのエンティティがあります。ユーザーはリクエストを作成し、後でミッションを作成して既存のリクエストをミッションに割り当てることができます。

リクエストとミッションは個別に作成できます。つまり、リクエストを作成するときにミッションを作成する必要はなく、その逆も同様です。

したがって、ここには 2 つの異なる集約があると仮定しています。要求集約とミッション集約であり、各エンティティは独自の集約のルートです。

ただし、この仮定に違反する不変条件があります。ミッションを延期またはキャンセルできます。これにより、それに割り当てられたすべてのリクエストのステータスがそれに応じて更新されます。

Request と Mission が 2 つの異なる Aggregate にある場合、この制約を強制するにはどうすればよいですか? それらを同じ Aggregate に入れると、各エンティティは個別に作成できるため、Aggregate Root が誰であるかを知ることはできません。

何かアドバイス？

モッシュ

ASP.NET MVC 2 と Entity Framework を使用して、初めての Web アプリケーションを構築中です。リポジトリ パターンを使用しています。Stack Overflow や他の Web サイトで収集した情報によると、コンセンサスは、ドメイン モデル オブジェクトごとに 1 つのコントローラーと、集約ルート オブジェクトごとに 1 つのリポジトリーを持つことです。

問題は、集約ルート リポジトリを介して非ルート集約オブジェクトにアクセスする方法です。私が扱っている例では、Customer モデルと Boat モデルがあります。ボートは顧客への FK 参照でのみ存在でき、ボートは顧客のコンテキスト内でのみ参照する必要があります。これにより、これら 2 つのオブジェクトを含む集約があり、Customer がルートであると信じるようになりました。

これで、Boats コントローラーに Edit アクション メソッドがあります。

私の質問は、リポジトリ内の Boat オブジェクトを取得するにはどうすればよいですか?

Customers リポジトリから db.Boats を参照することはできますか? これは最もクリーンなように思えますが、FakeCustomersRepository を変更して顧客とボートのリストを作成する必要があることを意味します。

db.Customers を介してボートにアクセスする方が合理的に思えましたが、LINQ クエリで自分自身を繰り返さずに単一のボート オブジェクトを返す方法がわかりませんでした。

まだ学ぶべきことがたくさんあることはわかっているので、正しい方向に向けていただければ幸いです。

ありがとう！

集約ルートを1;2;3でマークしました。とても素敵に見えます-ほとんどブドウのようです。

私が嫌いなものは、赤い矢印でマークされたエンティティです。

それを想像してみましょう：

• AR＃1は会社です
• AR＃2はオフィスです
• AR＃3は従業員です
• 赤い矢印でマークされたエンティティの名前はCountry
  • 会社は、従業員を雇用する国のルールを設定します（雇用に関してcompany.Countries.Contains(employee.Country)は真実でなければなりません）

私はどういうわけか、ドメインのこの非常に重要でない部分を見て（おそらくこの例ではそのように聞こえないかもしれません）、Countryを集約ルートに昇格させることは避けたいと思います。

骨材の根に関する用語集は次のように述べています。

内部メンバーへの一時的な参照は、単一の操作内でのみ使用するために渡すことができます。

つまり、「EmployeeCountry」のようなものを導入し、会社の国への参照を削除し、従業員の国が雇用業務でどの会社の国とも一致するかどうかを確認することは合理的に聞こえますか？

他のアイデアはありますか？

どうすればブドウを本来のように見せることができますか？

私はかなり前からドメイン駆動設計（DDD）を扱ってきましたが、Entity Framework（EF）は比較的新しいので、VisualStudioでEntityFrameworkDesignerを使用するときに頭に浮かんだ質問の1つは集計はEFで表現/モデル化する必要があります。

DDDのベストプラクティスに従うと、エンティティは同じアグリゲート内の他のエンティティ（または値オブジェクト）のみを参照する必要があり、他のエンティティへの参照はアグリゲートのルートエンティティ（アグリゲートルート）に制限されます。ただし、EFにこれらの概念が存在することはわかりません（つまり、すべてのエンティティが同様に扱われるため、エンティティ間の参照に制限は適用されません）。

したがって、私は尋ねています：私はEFで何かを見逃しましたか、それとも集約、集約ルート、およびエンティティ間の参照について完全に不可知論的ですか？後者の場合、Entity Frameworkを使用するときにAggregateをどのようにモデル化しますか？