問題タブ [aggregateroot]

私の元の質問はこちらです。

以下は私の更新されたコードです。

作業単位がコミットしようとすると、次のエラー メッセージが生成されます。

StockTransfer.RemoveItem() を使用すると、コレクションからアイテムが削除されますが、データベースにレコードが保持されるため、エラーが発生します。

集約ルートから子オブジェクトを削除し、集約ルートを永続化する方法はありますか?

私はレンタカーのウェブサイトのドメインでdddのいくつかの側面を研究しようとしています。

ユーザー/顧客は、出発地と目的地の駅と期間から車を選択します。

価格の計算は、支払い方法、時間、車の分類など、さまざまなものによって異なります。データは、アプリケーションの他の部分とはデータアクセス戦略が異なるサブシステムから取得されます。

ドメインには、ステーションサービス、コールセンターなど、いくつかのアクターがいます...

制限されたコンテキストのアイデアは

• 会社（従業員、車、駅）
• 予約（予約、予約リクエストプロセスのモデル）
• 価格（価格モデル）
• 請求（レンタル請求、ポジション、顧客）

境界付きコンテキストを定義した後、それぞれの集約されたルートが正しいかどうかわかりません。私の考えは

• 会社：3つすべて
• 予約：予約（請求書、車、顧客へのアクセス）
• 価格：料金表
• 請求：顧客（予約へのアクセス、請求）

必要に応じて、クラス図を追加して、さまざまな境界コンテキストを表示できます。さらに情報が必要な場合は、クラス図またはこれを他のセクションに移行する必要があります。お気軽に質問/実行してください。

関連するビットが次のように見えるEF 4.2を使用しています。

特定のユーザーを引き戻し、関連付けられたメンバーシップ オブジェクトを更新すると (失敗したパスワードの数を更新するなど)、メンバーシップ オブジェクトが更新されますが、ユーザー プロパティが更新されていないにもかかわらず、ユーザーも更新されます。これは、Membership オブジェクトが何らかの変更されたイベントを発生させ、親 User にバブルアップしたためですか?

これは、ユーザーをロードしてから、user.Membership ナビゲーション プロパティを使用するだけでなく、_context.Memberships.Find(userId) を使用してメンバーシップを取得しても発生します。コンテキストグラフでは、これら2つは同等だと思いますか?

変更された日付の計算値列を使用しているため、ユーザーオブジェクトの更新を停止する方法はありますか?子エンティティが変更されたときにこれが更新されないようにすることをお勧めします。理想的には、User プロパティの一部も読み取りたいので、Membership DbSet を照会するだけでなく、User オブジェクトをプルバックしたいと考えています。

親ユーザー テーブルで実行される SQL は次のとおりです。

MVC アプリケーションを開発しています。ドメイン モデルがあり、データ アクセスと Entity Framework Code First にリポジトリ パターンを使用しています。また、リポジトリ操作を呼び出す UnitOfWork クラスもあります。

私の問題は主に、集約ルートを利用し、親リポジトリを介して子オブジェクトを処理しようとしたときに発生します。

これが問題です。親クラス「サプライヤー」には、部門との契約がいくつかあります。この場合、コントラクトをサプライヤーの子にすることにしました。

新しい契約を追加するには、SupplierRepository に契約を追加するメソッドを追加する必要があります。

そして私も試しました：

私が電話するとき

次のようなエラーが表示されます。

エンティティ オブジェクトは、IEntityChangeTracker の複数のインスタンスによって参照できません

UnitOfWork は私の DbContext (myDbContext) と私の SupplierRepository をインスタンス化し、myDbContext.Save() を呼び出します

1. なぜこのような動作をするのですか
2. 集約ルート リポジトリを実装する方法 (子オブジェクトの CRUD 操作)

私が理解している限り、リポジトリにコントラクトを取得して追加するメソッドが必要であり、MVC アプリのコントローラーでこれを行う必要はありませんが、機能していないようです。

集約ルートに関する多くの情報を見てきましたが、それを実装する方法の例はありません。

ありがとう。

解決：

さて、私はついにそれを理解しました。

したがって、リポジトリの問題ではありませんでしたが、新しい SupplierContract は、ストアを作成したユーザー エンティティを (拡張メソッドを介して) クエリしました。明らかに、このコンテキストは破棄されなかったため、コントラクト エンティティを保存するためにインスタンス化したときに、現在の DbContext が 2 つありました。

うまくいけば、誰かがこれを読んで時間を節約できます。

SupplierRepository で次のようにするだけで解決した Aggregate Root リポジトリ:

そして UnitOfWork.Save() メソッドを呼び出します。

ドメイン駆動設計に手を出していると、ドメイン モデル内の集約ルートを特定する方法に関する状況に遭遇しました。

次の 3 つのクラスがあり、単純な To Do リストをモデル化しています。

モデルについて次のように述べることができます。

1. 更新は、タスクのコンテキスト内にのみ存在します。
2. タスクは、リストのコンテキスト内にのみ存在します。

したがって、リストは唯一の集約ルートのように見えます。(実際、私のデータ アクセス レイヤーでは、List オブジェクトの読み込みと保存のみが許可されます。)しかし、Task クラスに現在存在する UI を List クラスにきれいにプッシュする方法がわかりません。現在、私の List クラスは Task オブジェクトへの参照を配布しており、呼び出し元がそれらを変更できるようになっています。

これは、その存在が含まれているリストに依存している場合でも、タスクが集約ルートでもあることを意味しますか?

前もって感謝します。

親エンティティ コレクションから子エンティティを削除すると、EF によって子エンティティの状態が削除ではなく変更されるように設定されていることに気付きました。

エンティティ オブジェクト マネージャ内に、それを削除するように設定する別のプロパティはありますか?

以下は、変更された子アイテムを見つけて削除するために、EF リポジトリの Save メソッド内で使用しているコードです。

私が抱えている問題は、両方の状態が変更済みに設定されているため、更新と削除の違いを検出しようとしていることです。現時点では、レコードも更新するとアイテムが削除されます。2 つの状態を検出できますか?

バックグラウンド

Udi Dahan は、データ アクセスに使用する便利なパターンとしてフェッチ戦略を提案しています。同意します。

概念は、役割を明確にすることです。たとえば、集約ルート - 顧客があります。アプリケーションのいくつかの部分に顧客が必要です。選択する顧客のリスト、顧客の詳細のビュー、および顧客を非アクティブ化するボタンが必要です。

Udi は、これらの役割ごとにインターフェイスを提案するようです。そのため、購入した最新の 10 個の製品を含むICustomerInList非常に基本的な詳細と、顧客を非アクティブ化する方法があります。各インターフェイスは、それぞれの状況でジョブを完了するのに十分な数の Customer Aggregate Root を公開します。My Customer Aggregate Root は、これらすべてのインターフェースを実装しています。ICustomerDetailIDeactivateCustomer

ここで、これらのロールごとにフェッチ戦略を実装したいと考えています。各戦略は、必要な情報のみを公開するインターフェースの背後にあるため、集計ルートに異なる量のデータをロードできます。

この部分を実装する一般的な方法は、Service Locator または他のスタイルの依存性注入を要求することです。このコードは、たとえば、必要なインターフェイスをICustomerInList取得し、それをロードするためのフェッチ戦略を見つけます ( IStrategyForFetching<ICustomerInList>)。この戦略は、ICustomerInList インターフェイスに必要な情報を含む Customer のみをロードすることを認識しているクラスによって実装されます。

ここまでは順調ですね。

質問

Service Locator またはIStrategyForFetching<ICustomerInList>. 私が目にするすべての例は、既知の ID で 1 つのオブジェクトのみを選択しています。このケースは簡単です。呼び出し元のコードはこの ID を渡し、特定のインターフェイスを取得します。

検索したい場合は？それとも、顧客リストの 2 ページ目が必要ですか? ここで、Fetching Strategy が必要とするより多くの用語を渡したいと思います。

可能な解決策

私が見たいくつかの例では、述語 (特定の集約ルートが結果セットの一部である必要がある場合に true または false を返す式) を使用しています。これは条件には問題なく機能しますが、最初の n 人の顧客だけを取得する場合はどうでしょうか? または、検索結果の 2 ページ目を取得しますか? または、結果はどのようにソートされますか?

私の最初の反応は、汎用パラメーターを myIStrategyForFetching<ICustomerInList>に追加し始めることIStrategyForFetching<TAggregateRoot, TStrategyForSelecting, TStrategyForOrdering>です。これはすぐに複雑で見苦しくなります。リポジトリが異なると、さらに複雑になります。特定の選択方法を使用する場合にのみデータを提供するリポジトリもあれば、特定のタイプの順序付けのみを提供するリポジトリもあります。特定の方法でソートされた集約ルートのみを返す特殊なリポジトリとともに、ソート機能を使用できる一般的なリポジトリを柔軟に実装したいと考えています。

最初に使用したのと同じパターンを適用する必要があるように思えます - How do I make roles explicit? ペイロード Y (検索/順序付けパラメーター) を使用して X (集約ルート) を取得するための戦略を実装する必要がありますか?

編集 (2012-03-05)

毎回集約ルートを返さない場合でも、これはすべて有効です。各インターフェイスが異なる DTO によって実装されている場合でも、IStrategyForFetching を使用できます。これが、このパターンが強力である理由です。何を取得し、何を返すかを集約ルートにマップする必要はまったくありません。

使ってしまいましたIStrategyForFetching<TEntity, TSpecification>。TEntity は私が取得したいものであり、TSpecification は取得したい方法です。

私は EF Code First と遅延読み込みを使用します。

私の問題は、孫コレクション内のエンティティを効率的に更新する方法に関連しています。まず第一に、これにより、実際には必要のないデータベースで多くの呼び出しが行われるのではないかと心配しています。しかし、私のドメイン クラスが持続性を気にしないのであれば、これを行う別の方法が思い浮かびません。

クラスは次のとおりです。

サプライヤーは集約ルートです。だから私は ChangeDeliveryContract であるサプライヤーにメソッドを持っています、そしてそれは現実の世界で起こることに対応しています。

私は MVC を使用しているので、プログラムは次のようになります。

まず第一に、問題は ChangeDeliveryContract にあります。私はこれを機能させることができませんでした。また、私のようにコレクションを照会するのは非効率的かもしれません。第 3 に、30 以上のプロパティをマッピングするのも少し間違っているように感じます。

皆さんはどのようにそれを行いますか、そしてここにベストプラクティスはありますか?

現在も DDD について読んで学んでおり、現在取り組んでいるプロジェクトに適用しようとしています。私はまだ Aggregates に頭を悩ませようとしていて、興味深い質問に出くわしました。

2 つの集合体があり、1 つにはルート用のアカウント エンティティがあり、もう 1 つにはルート用のユーザー エンティティがあるとします。

アカウントはユーザーなしでは作成できませんが、ユーザーは作成できます。そのため、両方が独自の集計のルートとして機能します。Aggregates には他のエンティティが含まれますが、それは私の質問にとって重要ではないことに注意してください。

いくつかのビジネス ルール: 1) アカウントが作成されたら、それをユーザーに関連付ける必要があります。ユーザーが存在しない場合は、最初に作成する必要があります。

2) アカウントが削除された場合、関連するユーザーも削除する必要があります。

3) ユーザーの作成時に、アカウントに関連付ける必要はありません。

3) ユーザーが削除されるとき、それがアカウントに関連付けられている場合は、それも削除する必要があります。

Account と User は独自の集合体を形成するため、おそらく独自のリポジトリが存在します。つまり、標準の Add、Delete、Find、および Delete メソッドは、これらのリポジトリごとに定義されます。

これらのシナリオを考えると、次のことを達成するための最良の方法は何ですか: 1) アカウントが作成されたら、そのユーザーのプロパティでメソッドを呼び出して、ユーザーが存在することを確認することを考えました。これは正しいですか？

2) アカウントが削除された場合、関連するユーザーも削除するにはどうすればよいですか。アカウントリポジトリから？しかし、それはユーザー リポジトリでコードを複製するだけではないでしょうか? それとも、リポジトリは相互に参照して呼び出すことができますか?

3) ユーザーが削除された場合、それがアカウントに関連付けられているかどうかを判断し、コードを複製せずに削除するための最良の方法は何ですか (おそらく 2 番目の質問に似ています)。

ロジックが 2 つのエンティティまたは集計にまたがる場合は、サービスの使用を検討することをどこかで読みました。しかし、クライアント (API が進化し、ユーザーが将来的に他のプレゼンテーションを使用すると仮定すると) がサービスをバイパスして単にリポジトリを呼び出すのを止めているので、私はそれに満足していませんか?

更新 1:

これはおそらく関連する質問であることに気付きました:集約ルート間の関係と制約をどのように強制する必要がありますか?

私はDDDを初めて使用するので、用語や理解が少しずれている場合は実行してください。しかし、私を訂正してください、そしてどんなアドバイスも大歓迎です。

私がソーシャル求人掲示板サイトを運営していて、候補者、仕事、会社という総体的なルーツを特定したとしましょう。非常に異なるもの/コンテキストであるため、それぞれに独自のデータベーステーブル、リポジトリ、およびサービスがあります。しかし今、私はデータブロックが候補者、仕事、または会社のいずれかのデータを表示するPinterestスタイルのホームページを構築する必要があります。

ここで注意が必要なのは、データブロックが表す集合体に何かが最後に発生したとき（会社がいいね/コメントされた、またはジョブが更新されたときなど）までにデータブロックを並べ替える必要があり、ページングが無限スクロールの形で発生することです。 Pinterestのように。これらのアグリゲートは独立して発生するため、特定のページにどのアグリゲートがいくつあるかを知る方法がありません。（しかし、たとえば、アグリゲートの最終更新時刻を追跡するテーブルを作成した場合、これを独自のリポジトリを持つ別のアグリゲートルートに昇格させる以外に選択肢はありませんか？）

ページングロジックはどこに実装しますか？リポジトリごとに集約ルートごとに1つのサービスが必要であるとどこかで読んだので、コントローラーで並べ替えてページングする必要があります（ちなみにMVCを使用しています）？または、このような境界を越えたものを実行する独立したアプリケーションサービスが必要ですか？どちらの場合でも、dbからすべての集計のすべてのエンティティをフェッチする必要がありますか？

それはすでにあまりにも多くの質問ですが、私は基本的に尋ねています：

1. ページングプレゼンテーション、ビジネス、または永続性ロジックですか？どの水平層？
2. 境界を越えたコードはDDDのどこにあるべきですか？どの垂直スタック？