問題タブ [aggregateroot]

エンジニアがガス井にアクセスするアプリケーションがあります。彼は、7 つの特性の任意の組み合わせを選択して、井戸のリストを表示できます。特性は、会社、州、郡、流域、支店、分野、事業者の順で表されます。アプリケーションが起動し、会社のリストを取得する必要があります。ユーザーに表示される会社は、セキュリティ資格情報に基づいています。リポジトリのベースとなる集約ルート/ドメイン オブジェクトは何でしょうか。私は最初にユーザーを考えましたが、ユーザーについて何も取得しませんでした。これらの項目とその他のいくつかの属性の組み合わせは、まとめて坑口情報と呼ばれます。それはリポジトリの集約ルートまたはドメイン オブジェクトでしょうか?

前もって感謝します

ドメイン駆動設計の基礎を理解しようとしています。昨日、私が取り組んでいるプロジェクトで、リポジトリがエンティティのリストを返したコードを見つけました。ここで、DDD のリポジトリについて読むと、リポジトリが集約ルートを返す必要があること、および集約に対するアクションは集約ルートのメソッドを呼び出して実行する必要があることがかなり具体的です。

リストを独自のクラスに配置して、そのクラスを返すだけです。ただし、私のプロジェクトでは、メッセージを表示するか、新しいメッセージを追加するか、既存のメッセージを削除するだけなので、DDD への準拠を除いて、基本的にそれを行う必要はありません。すべてのメッセージを削除する必要はないので、メソッドはaddMessage(...)、getMessages()、updateMessage(...)およびのみremoveMessage(...) です。これは、基本的にドメイン サービスが行っていることです。

アイデアはありますか？Aggregate と Repositories を記述する際の DDD のベスト プラクティスは何ですか?

私は現在 DDD で多くの作業を行っていますが、他の集約ルートから集約ルートをロード/操作するときに問題に直面しています。

モデルの集約ルートごとに、リポジトリもあります。リポジトリは、ルートの永続化操作を処理します。

いくつかのメンバー (エンティティと値オブジェクト) を持つ 2 つの集約ルートがあるとします。

AggregateRoot1 と AggregateRoot2。

AggregateRoot1 には、AggregateRoot2 を参照するエンティティ メンバーがあります。

1. AggregateRoot1 をロードするとき、AggregateRoot2 もロードする必要がありますか?
2. AggregateRoot2 のリポジトリがこれを担当する必要がありますか?
3. もしそうなら、AggregateRoot1 のエンティティが AggregateRoot2 のリポジトリを呼び出してロードしてもよろしいですか?

また、AggregateRoot1 のエンティティと AggregateRoot2 の間の関連付けを作成する場合、エンティティを介して行う必要がありますか、それとも AggregateRoot2 のリポジトリを介して行う必要がありますか?

私の質問が理にかなっていることを願っています。

[編集]

現在のソリューション

Twith2Sugarsの助けを借りて、次の解決策を思いつきました。

質問で説明されているように、集約ルートには、他のルートへの参照を持つ子を持つことができます。root2 を root1 のメンバーの 1 つに割り当てる場合、root1 のリポジトリはこの変更を検出し、これを root2 のリポジトリに委譲する役割を果たします。

これは単なる例であり、デメテルの法則やその他の最善の原則/実践は含まれていません:-)

さらなるコメントをお待ちしております。

Domain Driven Design について、Order と OrderLines は常に集約として見なされ、Order がルートになります。通常、注文が作成されると、それを変更することはできません。しかし、私の場合、それは可能です。代わりに、各注文には、注文を変更できるかどうかを決定する状態があります。

この場合、Order と OrderLines はどちらも独自の「集約ルート」ですか? 注文明細を更新できるようにする必要があるため、注文明細には独自のリポジトリが必要であると考えています。しかし、注文明細を取得したくなく、注文なしで永続化します。したがって、これは、Order がルートであり、注文明細行を作成するためのファクトリ メソッド (Order.CreateOrderLine(quantity, text, …) を持つ集約がまだあることを示しています。

もう 1 つの方法は、注文明細行のコレクションが変更されたときに Order を更新してから、UpdateOrder(Order) を呼び出すことです。コレクションのみを更新する必要があり、Order 自体は更新しないことを (Entity Framework を使用して) 検出する何らかの方法が必要です。どう思いますか？

Domain-Driven Design: Tackling Complexity in the Heart of Software の次の定義に基づいて、

集約とは: データ変更の目的で 1 つの単位として扱われる、関連付けられたオブジェクトのクラスター。外部参照は、ルートとして指定された AGGREGATE の 1 つのメンバーに制限されます。AGGREGATE の境界内では、一連の整合性ルールが適用されます。

Aggregate ルートがリポジトリへの参照を保持する必要はないと思います。Aggregate ルートは、そのエンティティと集計への参照を保持する必要がある唯一のルートであるため、非公開にする必要があります。

私のリポジトリはどのようにしてこのプライベート データを保持し、復元できますか?

編集：

古典的な Order、OrderLines の例を見てみましょう。

オーダーは集約ルートです。

その線はエンティティです。

Aggregate ルート (注文) は、そのエンティティ (注文明細) への参照を保持できる唯一のオブジェクトであるため、リポジトリから注文明細を保持する方法がわかりません。

問題は、2 つの集計ルートがあることです

集約ルートは

1. 計画。
2. ニュース記事。

プロジェクトは、関連する NewsArticle のコレクションを持つことができます。NewsArticle は、関連するプロジェクトのコレクションを持つことができます。

要件は次のとおりです。

1. ユーザーは、プロジェクトから多数の NewsArticle を関連付けることができます。
2. ユーザーは、NewsArticles から多数のプロジェクトを関連付けることができます。

データベース内。

NewsArticle --* NewsArticleProject *-- プロジェクト。

マッピングで

ニュース記事面

プロジェクト側

私も試しHasMany()ましたが、設定した ColumnName について不平を言うエラーメッセージが表示されます。

私の要件を満たすことができるように、流暢なnHibernateをマッピングにうまく組み込むのに苦労しています。

片側だけで動作させることはできますが、反対側で動作させようとすると、このエラーメッセージが表示されます。

多対多のプロパティ 'FeaturedNewsArticles' の反対側がどうあるべきかわかりません。

誰かが解決策を考え出すのを手伝ってくれるなら、事前に感謝します。

データモデルでリポジトリパターンを実装することについて質問があります。オンラインで検索してたくさんの投稿を調べましたが、疑問を解消する答えは見つかりませんでした。基本的に、ドメインモデルは次のようになります。多くの子オブジェクトを持つクライアントオブジェクトがあり、一部の子オブジェクトには子オブジェクトがあり、いつでも親オブジェクトのないこれらの子オブジェクトは不要であり、作成されません。アプリケーションの任意の意味。

そしてそれはこのようになります。上記の表現から、いくつかのアグリゲートがあり、ルートはクライアントオブジェクトであるため、クライアントであるアグリゲートルートレベルでリポジトリを作成することを考えていました。私の質問は、他の集計をどのように処理するかです。誰かが私にこれに関するいくつかのアイデアを提供できますか？

ありがとう、アジェイ。

Aggregate Root パターンをドメインに適用しようとしています。POCO Entity GeneratorでEntity Framework 4を使用しています。

2 つのエンティティがあります。 MailingTask EmailLog 1 対多の関係があります。(MailingTask には多くの EmailLogs があります)。EF4 は、MailingTask でナビゲーション プロパティを生成します。

私のモデル内では、EmailLogs に直接アクセスしたくはありません。常に親の MailingTask を介してアクセスします。これは、次の方法で実施されます。

• MailingTask リポジトリしかないため、EmailLogs テーブルを直接クエリすることはできません。
• このナビゲーション プロパティのみを介して EmailLogs を取得します。

MailingTask の EmailLogs の数を数える必要がある場合があります。これは、ナビゲーション プロパティで LINQ を使用することによって実現されます。

ただし、これは (データベース サーバーではなく) アプリケーション側で実行されます。(そして、MailingTask 用の EmailLogs がたくさんあるので、非常に高価です。) この動作に関するいくつかの投稿を読んだところ、EF4 ナビゲーション プロパティを IQueryable (データベース側で実行) として使用できないようです。ナビゲーション プロパティにアクセスすると、EF4 はメモリ内のすべての列を含むすべてのエントリを読み込み、メモリ内の LINQ 式を適用します。Count() ステートメントの場合、これは非常に厄介です。

この特殊なクエリに対応するには、モデルを変更する必要があると思います (クエリ機能を備えた EmailLogsRepository を追加する可能性があります)。私にとっては、EF4 は Aggregate Root パターンをうまくサポートしていないようです。それとも、Aggregate Root パターンと、EF4 に関してそれをどのように実装する必要があるかについて何かが欠けているかもしれません...

誰かがこの状況に遭遇し、これを解決できましたか? nHibernate または別の ORM はこれをより適切にサポートしていますか?

ドメインモデルを少し理解し、設計に正しくアプローチしていることを確認するために、いくつかの助けを借りることができます。

Departmentという集約ルートがあります。Departmentオブジェクトには、「department」のビジネス概念を定義するのに役立ついくつかの子値タイプがあります。私のUIでは、ユーザーは部門オブジェクトを一覧表示、作成、編集、および削除できます。

Projectという別の集約ルートがあります。プロジェクトにはいくつかの子値タイプがありますが、各プロジェクトが部門によって「所有」されているという点で部門とも関係があります。プロジェクトは作成、編集、削除などが可能であり、そうしても部門に影響はありませんが、部門を削除すると、所有しているプロジェクトもすべて削除されます。

私のUIには、現在のユーザーがアクセスを許可されている部門に基づいたプロジェクトのリストが表示されます。複数の部門にアクセスできる場合があります。リストアイテムと詳細の両方として表示される場合、プロジェクトで部門のロゴを表示する必要があります。

私が最初に考えたのは、プロジェクトは、部門を「検索」するために使用できる単純なDepartmentIDプロパティを持つ集約ルートであるということでした。しかし今、私は実際には1つの集約ルート（Department）しか持っていないと考え始めています。

どう思いますか？

アップデート

それが議論の鍵なのか、何かを変えるのかはわかりませんが、最初のいくつかの答えを読んだ後、次のような考えが浮かびました。

部門には2つのコンテキストがあるようです。

1. 変更をサポートするスタンドアロンエンティティとして。
2. プロジェクトの子として、この場合は読み取り専用データが含まれ、動作はありません。

これにより、モデルに2つの「オブジェクト」（ケース＃1の集約ルートとケース＃2の値型）が必要だと思います。私は正しい方向に進んでいますか？