問題タブ [aggregateroot]

私は、さまざまな集合ルートのセットを持つリッチ オブジェクト モデルを持つプロジェクトに取り組んでいます。

Castleスタック (モノレールから ActiveRecord を使用した nHibernate まで) を使用しています。

集約ルートを遅延としてマークし[ActiveRecord(Lazy = true)]、オブジェクト グラフを熱心にフェッチするために、リポジトリで「熱心な」ルーチンをカスタマイズしました。HQL を使用して、ルートの子コレクションから熱心なフェッチを定義します。

たとえば、集約ルート (および遅延ロードとマークされている)の場合、完全なグラフのエンティティをAccount熱心にフェッチします。Account .. Order .. Product

したがって、これまでのところ驚くことはありません（うまくいけば）。

上記の例で、Product もマークされている場合[ActiveRecord(Lazy = true)]、HQL の熱心なフェッチ ディレクティブが停止しているように見えます。

遅延ロードされた子オブジェクトの熱心なフェッチを強制する方法を知っている人はいますか??

乾杯イアン

更新：

ここに hql の例があります。以下の「me.yahoo.com/../1」の例を使用すると、IMuliQuery を使用して、多対多の関係をフェッチするときに N+1 の依存関係を解決しています。また、多対多のマッピング クラスを明示的に使用しています。その結果、本社は次のようになります。

...これにより、2 つの sql ステートメントが実行され、必要な最小限の行セットが返されます。これを単一のオブジェクト グラフに解決できます。良い。

しかし...たとえば、Address遅延ロードとマークされた（そしてOrderそうではなかった）場合、アクセスOrderはそれ以上のSQLステートメントをトリガーしませんAddressが、どちらも熱心にロードされているにもかかわらず、アクセスは実行します。

Addressでは、上記の遅延ロードされたエンティティが上記のステートメントによって熱心にフェッチされないのはなぜでしょうか?

多くの Y を持つ集約ルート X と、多くの Z を持つ Y があるとします。

アソシエーションをドリルダウンして、Z が特定のプロパティ値を持つ X のみを選択するにはどうすればよいですか?

IList Xs = Session.CreateCriteria(typeof(X)) .CreateAlias("Ys", "Y") .CreateAlias("Y.Zs", "Z") .Add(Expression.Eq("Z.Property", 1 )) .リスト();

これを行うと PropertyAccessException が発生し、その理由がわかりません。

すべての X をロードして Z プロパティをテストすることは、非常に冗長です。

必要なエンティティ ツリーをロードするための、より構造化されたアプローチを作成したいと思います。

かなりの量のデータが必要なので、ここに示すように、タイプ セーフなインクルード (通常のインクルードですが Lambda を使用) を使用してこれを行っています。

私が言ったように、基本的には 1 つの親アイテムの下にあるエンティティ ツリー全体である、大量のデータが必要です。

今、私はこれを次のように行うことができます：

ご覧のとおり、インクルードで満たされたこの行は非常に大きくなる可能性があります。実際、これは実際のコードの非常に単純化されたサンプルです (住宅は含まれていません)。

だから私がやりたいのは、ツリー内のブランチを担当するメソッドを作成することです。メソッドがオブジェクトクエリを受け入れて子を含めることができる場所で、次に「子ローダーメソッド」を呼び出します。また、子の型を持つプロパティがある限り、親は重要ではありません。

これはおそらくあまり意味がありません:

等々。しかし、私は本当にそれを理解することはできません... 着信クエリと子メソッドの呼び出しとの間にリンクがありません。

誰かがこのようなことをしましたか？または、誰かが私にいくつかの指針を与えることができますか?

Foo と Bar という 2 つのエンティティがあるとします。Foo は集約ルートであり、Bar を含みます。私が理解している限り、次のようになります。

ユーザーが定義済みリストから Foos の Bars を選択 (および変更) できる機能を提供したいと考えています。

リポジトリが集約ルート専用であると想定されている場合、Bar エンティティのリポジトリがないことを意味します。

これは問題につながります - Foo への参照なしで Bar を独立して作成/更新することはできません。

それは、Foo がなければ意味がないにもかかわらず、Bar にはリポジトリがあるはずだということですか?

うまくいけば、この架空の例が私の問題を説明するでしょう:

ソフトウェア製品に関する苦情や、製品に関するその他の多くの属性を追跡するシステムを作成しているとします。この場合、SoftwareProduct は集約ルートであり、Complaints は製品の子としてのみ存在できるエンティティです。つまり、ソフトウェア製品がシステムから削除された場合、苦情も削除されます。

システムには、単一の SoftwareProduct のさまざまな側面を表示する Web ページのようなダッシュボードがあります。ダッシュボードの 1 つのセクションには、グリッドのような形式で苦情のリストが表示され、各苦情について非常に高レベルの情報のみが表示されます。管理者タイプのユーザーがこれらの苦情のいずれかを選択すると、単一の苦情の詳細を編集できる編集画面が表示されます。

問題は、編集画面で単一の苦情を取得し、編集目的で表示できるようにするための最良の方法は何ですか? SoftwareProduct は既に集約ルートとして確立されているため、苦情への直接アクセスは許可されないことに注意してください。また、システムは NHibernate を使用しているため、eager loading はオプションですが、SoftwareProduct を介して 1 つの Complaint をeager load しても、Complaints コレクションにアクセスするとすぐに残りのコレクションが読み込まれると理解しています。では、Complaints コレクション全体をロードするオーバーヘッドを発生させずに、SoftwareProduct を介して単一の Complaint を取得するにはどうすればよいでしょうか?

リポジトリパターンを適切に使用する方法について頭を悩ませようとしています。Aggregate Root の中心的な概念が次々と出てきます。Web とスタック オーバーフローの両方で集約ルートとは何かについてのヘルプを検索すると、それらに関する議論と、基本定義が含まれているはずのページへの無効なリンクが見つかります。

リポジトリ パターンのコンテキストでは、集約ルートとは何ですか?

ユーザーがイベント ページで電子メール アドレスを入力したときに、イベント リマインダーを追加する必要があります。イベントは別のドメイン オブジェクトです。最初に考えたのは、Customer ドメイン オブジェクトと関連する CustomerService を作成することでした。

新規顧客に対して AddEmailReminder メソッドが実際に呼び出されたことを単体テストで確認するにはどうすればよいでしょうか。

私の考え：

1. ファクトリを使用して顧客を作成します。オブジェクトの作成が複雑な場合にのみファクトリを使用することになっていると思っていたので、これはにおいがします。
2. 悪いコード。多分これを行うためのより良い方法がありますか？
3. モクマジック。

別のメモとして (関連している可能性があります)、ここで集約ルートをどのように決定するのでしょうか? 私たちは顧客を勝手に決めましたが、それはイベントでもあります。集約ルートに関する記事を読んで理解しましたが、このシナリオでは不明です。

顧客と注文明細を関連付けるOrderタイプの集約ルートエンティティがあるとします。注文エンティティについて考えるとき、IDなしで定義されていないものとして概念化する方が自然です。IDのない注文は、注文よりも注文リクエストとして表現する方が適切なようです。

リポジトリに注文を追加するために、私は通常、IDなしで注文をインスタンス化してから、リポジトリにオブジェクトを完成させるのを目にします。

このアプローチで私が気に入っているのは、OrderインスタンスをOrderRepositoryに追加していることです。それは非常に理にかなっています。ただし、注文インスタンスにはIDがなく、リポジトリのコンシューマーの範囲では、注文にIDがないことは私には意味がありません。OrderRequestをorderのインスタンスとして定義し、それをリポジトリに追加することもできますが、それはオレンジからリンゴを派生させて、それをオレンジのリストに追加するようなものです。

あるいは、私はこのアプローチも見ました：

このアプローチで私が気に入っているのは、IDがないと順序が定義されていないことです。リポジトリは、注文のインスタンスを作成して返す前に、データベースレコードを作成し、すべての必須フィールドを収集できます。ここで臭いがするのは、実際に注文のインスタンスをリポジトリに追加することは決してないという事実です。

どちらの方法でも機能するので、私の質問は次のとおりです。これら2つの解釈のいずれかを使用する必要がありますか、それとも挿入をモデル化するためのベストプラクティスがありますか？

私はこの答えが似ていることを発見しましたが、値オブジェクトの場合： 集約ルートによって維持されているコレクションにオブジェクトを追加するにはどうすればよいですか？値オブジェクトに関しては混乱はありませんが、私の質問は、外部ソース（自動生成されたデータベースID）から派生したIDを持つエンティティに関するものです。

現在のプロジェクトにリポジトリ パターンを使用しようとしています。現在、ドメインをモデル化し、集約ルートを見つけようとしています。

ルートが削除されたときにメンバーを削除する意味がない場合は、ルートの一部であってはならないという「Cascading Delete」ルールを読みました。

例として警察の事件を使用します:-

インシデント (集約ルート) - これには、調査担当者、各担当者によって作成されたメモが含まれる場合があります。また、インタビューされた日付のリストとともに容疑者を含めることもできます。事件の CCTV 映像は取得されましたか? CCTV が閲覧された各時間のログと誰が? 証拠/裁判所などのためにCCTVのコピーが作成されましたか

すべてがそのインシデントにかかっているように見えるため、IncidentAggregate が巨大になる可能性があるようです。

私の質問は 2 つあります。集約ルートはどの程度管理する必要があるか、およびルート内のルートは良い考えですか?

おそらく警察の事件のようなものを削除することはおそらくないので、これは特に良い例ではないかもしれませんが、私の質問をよりよく説明していることを願っています.

私は DDD を始めたばかりで、データのリレーショナルな性質に対応する方法を理解するのに苦労しています。集約ルートと見なされると思われるものがありますが、集約には独自の集約もあります。デメテルの法則に違反したくないので、私はこれについて間違った考えを持っているのではないかと考えており、DDD の専門家が何らかの洞察を提供してくれることを望んでいます。

私の集約ルートは、それ自体が個々のエンティティの論理グループであるAccount多数のエンティティの集約を持つオブジェクトです。AccountElementProductComponent

anAccountElementのコンテキストの外側には意味がないので、オブジェクトが集計ルートでAccountあるという結論に満足しており、そのエンティティが集計プロパティを持つことを期待しています。それは私を混乱させたコレクションです。この集合体は 以外では意味がなく、実際には 以外では意味がありません。AccountElementsProductComponentAccountElementAccount

ProductComponent次のように、点を打って個々のオブジェクトにアクセスする必要はないと思います。

But at the same time it doesn't make sense (from a domain perspective) to access a ProductComponent directly from an Account entity.

I'm sure that this is all a little difficult to comprehend without knowledge of my domain, but I'm hoping it's enough to get some good feedback.