問題タブ [aggregateroot]

例：データベースに「CustomerOrdersOnHold」という名前のSQLビューがあります。このビューは、特定の顧客データフィールドと注文データフィールドのフィルタリングされた組み合わせを返します。アプリケーションのこのビューからデータをフェッチする必要があります。このようなビューへのアクセスは、リポジトリパターンにどのように適合しますか？「CustomerOrdersOnHoldRepository」を作成しますか？このような読み取り専用ビューは集約ルートと見なされますか？

DDD を使用してプロジェクトをリファクタリングしていますが、あまりにも多くのエンティティを独自の集約ルートにしないことが心配です。

StoreのリストとProductOptionのリストを持つがありProductます。AProductOptionは複数の s で使用できますProduct。Storeこれらのエンティティは、集計に非常によく適合しているようです。

次にOrder、一時的に a を使用してそのsProductを構築する があります。OrderLine

今のところ、DDD ルールは尊重されているようです。しかし、集計のルールに違反する可能性がある要件を追加したいと思います。ストアの所有者は、特定の製品を含む注文に関する統計を確認する必要がある場合があります。

つまり、基本的に、OrderLine で Product への参照を保持する必要がありますが、これはエンティティ内のメソッドで使用されることはありません。この情報は、データベースにクエリを実行する際のレポート目的でのみ使用されます。したがって、この内部参照のために Store 集約内の何かを「壊す」ことはできません。

この単純な要件は、製品が集約ルートになることを示していますか? これはまた、ProductOption が集約ルートになるようにカスケードし、Product がそれへの参照を持っているため、ストアの外では意味を持たず、リポジトリを必要としない 2 つの集約になります。私には奇妙に見えます。

どんなコメントでも大歓迎です！

エンティティごとのリポジトリから集約ルートごとのリポジトリにアプリケーションをリファクタリングしようとしています。

基本的な例として、Cars のエンティティ ルートがあるとします。車にはレンタカー契約があります。私が見る限り、契約は車なしでは存在しないため、車は集約ルートです。

システム内のすべてのコントラクト (ルート エンティティのすべての子エンティティ) を表示するユーザー ビューを実装しようとしています。リファクタリングする前に、コントラクト リポジトリに移動して All を取得するだけで済みました。コントラクト リポジトリが削除されたため (ルートではないため)、すべての車をリポジトリから取り出して、すべてのコントラクトを取得する必要があります。

私のリポジトリにはインターフェースがあります

ICarManagementService を作成し、GetAllContracts メソッド (おそらくフィルター パラメーターを使用) を持たせることを考えました。それは、契約ですべての自動車エンティティを引き出してから、雇用契約に関連付けられている各エンティティを取得してそれらをフィルタリングするために必要なすべての契約を取得することを意味しますか?

次に、これらをコントローラーに渡し、以前と同じようにコントラクトを AutoMap します。

これはベストプラクティスですか？

ありがとう

グレアム

次のシナリオで、何がより良い、またはより正しいプラクティスと見なされるのか疑問に思っています。

NHibernateを使用して次のビジネスエンティティをマッピングしました。

• 壁
• WallPost
• WallPostComment

壁には0から多数のWallPostがあります。WallPostには0から多数のWallPostCommentsがあります。集約ルートはWallです。

WallPostCommentをWallPostに追加するタスクを書いています。アプリケーションはMVCアプリケーションであり、新しいWallPostCommentを追加するリクエストには、コメントが属するWallPostのIDが含まれています。コメントを追加するには、追加する必要のある投稿を取得する必要があります。私の質問は：これを行うための最良/最も正しい方法は何ですか？

私はこれまでに2つのアプローチを試しましたが、非効率的ですが、1つはより「正しい」と感じています。別の、より効率的なアプローチは「間違っている」と感じます。

1）セッションからWall集約ルートをロードし、PostsコレクションからFirstOrDefaultを選択します。これは、集約ルートを介してウォールポストにアクセスしているという点で「正しい」と感じますが、これを行うと、すべてのウォールポストがデータベースからフェッチされます（無制限の結果セット）。

2）リクエストによって渡されたwallPostIdを使用して、セッションから直接ウォールポストをロードします。集約ルートを回っているため、これは「間違っている」と感じますが、データベースで1行のデータが1回ヒットするだけです。

どちらがより良いまたは好ましいアプローチですか？他にどのような提案がありますか？

依存オブジェクトを集約ルートとしてモデル化する必要があるかどうか疑問に思います。私が a を持っていてTaskList、このリストにTasks があるとしましょう。はなしTaskでは存在できませんが、TaskList個別に表示および編集できます。タスクが変更または追加されたときにチェックできる特別な条件はありませんTaskList。これが集約ルートの主な理由になると思います。唯一の条件は、TaskListとそのタスクを所有者のみが編集できることです。TaskListに所有者がいて、TaskList を介してのみ Task を編集できる場合、この状態を確保するのは簡単です。それ以外の場合は、所有者をtransetivlyに検出するか、所有者フィールドをタスクに追加する必要があります。

では、ここでは何が適切ですか？

• Task と TaskList は両方とも集約ルートであり、それぞれに所有者フィールドがあります
• 集約ルートとして TaskList のみ、従属エンティティとして Tasks

私は何か重要なものを見逃していますか？

ドメイン モデルはエンティティ間の関係を定義し、集約ルートを定義してカプセル化とトランザクション境界を提供します。よく知られている関係は、1 対 1 の関係 (エンティティまたは値オブジェクトが集約ルートに含まれる)、1 対多の関係 (集約ルートに子オブジェクトのコレクションが含まれる)、および多対多の関係です。集約ルート間の多対多の関係により、トランザクション境界で問題が発生するため、後者は困難です。したがって、多くの場合、多対多の関係の 1 つの方向がより重要であると見なされ、その関係のみが 1 対多の関係としてモデル化されます。
では、さらに一歩進んでください。ネットワーク。同等のパートナー間の多対多の関係。集約ルートのトランザクション境界に違反することなく、どのようにモデル化できますか?
この広く適用可能な例を見てください:
ノードを持つネットワークがあります。各ノードには限られた数のポートがあります。1 つのポートは、別のノードの 1 つのポートにのみ接続できます。ポートを使用して、ノード間の接続を追加および削除できる必要があります。
これに対する直感的なアプローチは、ポートを含む集約ルートとしてノードをモデル化することです。接続は値オブジェクトのように見え、1 つのポートが 1 つの接続を持つことができます。接続 (ノード A のポート X とノード B のポート Y の間) を集約ルートであるノード A に追加する Node.ConnectTo(nodeId, portId) メソッドを実装できます。ノード A とノード B で 1 回、トランザクションでラップします。ただし、これはトランザクション境界に違反するため、ノード A にのみ保存することにしまし
た。 アプリケーション クライアントでノード B の接続を確認するには、別の読み取りモデルが必要になります。しかし、それは問題ではありません。CQRS アーキテクチャは、これらの可能性を提供してくれます。したがって、接続の追加、削除、表示は問題ありません。
ポートに接続を追加する前に、ポートがまだ空いているかどうかを検証したいときに問題が発生します。トランザクション境界を尊重した結果、(書き込みモデルでは) ポートが既に接続されているという事実が集約ルートには認識されない可能性がありますが、他の集約ルートに格納される可能性があります。
もちろん、クライアントの検証を信頼し、追加先のノードに問題がなければ接続を追加し、一貫性チェックを実行するプロセスに依存して、無効な接続の補正アクションを実行することもできます。しかし、2 つの ConnectTo 呼び出しの周りにトランザクションをラップすることに比べて、それは私にとっては大したことのように
思えます...これにより、集計ルートが間違って選択された可能性があると思いました。. そして、ノードとネットワークを集約ルートとして考え始めました。ここで、ネットワークは接続のコレクションです。ネットワーク集約の良い点は、接続の追加または削除をいつでも検証できることです。ただし、新しい接続によって既存の 2 つのネットワークが結合される場合を除きます。集合体が大きくなり、単一の巨大なネットワークになる可能性があります。実現不可能です。
では、これをどのようにモデル化する必要があると思いますか? 集約ルートをトランザクション境界として尊重し、ネットワークを検証でき、ネットワーク全体を 1 つの集約として保存するリスクを負わないソリューションが見つかりますか? それとも、ここで 3 つの CAP をすべて要求していますが、それは単に不可能なのでしょうか?

着信HTTPリクエストをスレッドにバインドされたイベント処理アクターに送信されるイベント（ケースクラス）に変換する薄いWebレイヤー（Scalatra ）があります。一部のイベントには、さまざまな理由で変更する必要がある集約ルートのIDが含まれています。アプリケーションデータの総量が大きすぎてメモリに収まらないため、操作する前に、データソースからIDで集計を取得する必要があります。もちろん、イベント処理アクターをブロックしたくないので、新しい（イベントベースの？）データをロードし、変更してデータソースに保存するアクター。理想的には、データソースのACID機能に依存するのではなく、アプリケーションで同時実行性を処理したいと思います。基本的に、各アグリゲートへのシリアル化/トランザクションアクセスが必要です。

これはアクターを使用して達成できますか？最善のアプローチは何でしょうか？ConcurrentHashMap集約ルートIDにキー設定されたアクターを含むイベント処理アクターの内部を維持しますか？

それとも、STM：s（ScalaSTM / Akka）などを使用する必要がありますか？

DDD を使用するプロジェクトに取り組んでいますが、ルックアップ エンティティの処理方法に行き詰まっています。たとえば、「Customer」という集約があり、エンティティ「Customer」も集約ルートです。エンティティ「Customer」にはプロパティ「CustomerTypeID」があります。

ただし、既存のすべての顧客タイプ (ID と説明) を表すエンティティ "CustomerType" もあります。ユーザーが顧客タイプを維持できるようにする管理機能があります (つまり、新しい顧客タイプを追加するなど)。

特定の顧客の顧客タイプを変更することについて話しているのではなく、顧客タイプのリストを維持することについて話していることに注意してください。

長々とした話で恐縮ですが、質問させてください。

• 「CustomerType」は値オブジェクトではなくエンティティであると考えるのは正しいですか?

• 「CustomerType」は集約「Customer」内にある必要がありますか?それとも、特定の顧客のコンテキスト外でアクセスして維持するため、独自の集約内にある必要がありますか?

• このエンティティと、基本的なルックアップ エンティティ (顧客ステータス、製品タイプなど) であるその他のエンティティが、それ自体で集計されるべきである (およびこれらの集計の集計ルートである) 場合、何百ものリポジトリになることはありません。 ? (各集約ルートには独自のリポジトリがあるため)

ご覧のとおり、私はここで混乱しているので、正しい方向に向ける必要があります。

================================= eulerfx の返信に返信するコードを書き込もうとしましたが、できませんでした'動かないのでここに置いておきます。

ポイント 2 に関しては、画面上では明らかにタイプの説明 (「個人」など) のみを表示します。それは私がこのようなものになってしまうことを意味しますか?:

と

Public Class CustomerType Inherits EntityBase(Of Integer) Implements IAggregateRoot

または、クラス「Customer」内のプロパティを CustomerTypeID にする必要がありますか?

ポイント 3 に関して、集約コンテキストと境界コンテキストの違いは何ですか? Customer のコンテキスト内にのみ存在するエンティティと値オブジェクトも含む "Customer" 集計 ("Customer" が集計ルートである) は、境界付けられたコンテキストではありませんか?

現在、システムのリファクタリングを行っています。

次の状況があります。

このシステムは、複数のビジネス セクターにまたがる企業に関する情報を提供することを目的としています。各企業は、1 つまたは複数のセクターで活動することができます。企業は特定のパートナー プログラムに参加できます。企業は、1 つまたは複数のパートナー メーカーを持つことができます (たとえば、ガレージは BMW/メルセデスとパートナーシップを持つことができます)。これらの参加はすべて、一定の期間 (有効期間) 存在します。さらに、BMW のようなメーカーは、1 つのビジネス セクターに縛られています。そのため、BMW が企業のビジネス セクターに有効である場合にのみ、企業は BMW のパートナーになることができます。つまり、このシステムは、ガレージのようなビジネス部門の企業を維持するだけでなく、レッカー サービスなども維持するためです。

だから今、私のデザインはいくつかの不変条件を引き起こす可能性があります。

会社 -> 割り当て (ゆっくりと変化しない) -> 事業部門

会社 -> パートナーシップ (日付から - まで) -> 組織 <- 事業部門

会社と組織が同じ事業部門の割り当てを共有する必要がある場合。

したがって、現在、組織の事業部門の割り当てを変更することができます。すると、同じ業種は無効というルールになります。

そのようなものをどのようにモデル化しますか？

優先されるコミュニケーションは何ですか：IAggregationRootマーカーは契約に保存されDomain LayerてData Access Layer参照されますか、IRepositoryまたはその逆ですか？

編集

パターンの実装Tim Maccharty's（http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470147563,descCd-authorInfo.htmlrepository pattern ）を見ました。unit of workユニットテストの目的で、の独自の/偽の実装があると非常に便利ですIUnitOfWorkRepository。そのような契約書をどこに保管すればよいのか、もう少し混乱しました。

ありがとう！