2

タイトルのとおり、次のクラスがあります。

public class Company : AggregateRoot {
    public AddressBook AddressBook { get; set; }
}

public class AddressBook {
    public List<Address> Addresses { get; set; }

    public Address GetPrimaryAddress() {
        return Addresses.FirstOrDefault();
    }
}

電話してもよろしいですか？

company.AddressBook.GetPrimaryAddress();

または、メソッドを順番に呼び出すGetPrimaryAddress()メソッドを公開する必要がありますか?CompanyAddressBook

AggregateRoot 内のエンティティへの参照を持つべきではないことはわかっていますが、操作の呼び出しに関する規則が何であるかはわかりませんでした。

アップデート

参考までに、以下は私の実際のモデルの図 (フルサイズはここをクリック) です。主要な連絡先が削除された場合の処理​​など、すべてのタイプの連絡先 (個人/ビジネスの場所) を管理する方法に関するルールが含まれています。また、RavenDB がネストされたエンティティを格納する方法に関するいくつかの注意事項も回避します (基本的に、独自の Id 戦略を提供する必要があります。そのため、LastContactId プロパティが必要です)。ContactList

クライアント モデル

4

3 に答える 3

2

まず第一に、それはすべてコンテキストに依存し、Company は実際にはその特定のコンテキストの AR であると思います。他のコンテキストでは、同じ Company が単純なオブジェクトになる場合があります。さて、私はルールとパターンの独断的な使用のファンではないので、「ルール」が何を言っているかは重要ではありません。

この場合、住所は社内のものと思われるため公開しません。Company の coosnumer として、私はその主な住所が欲しいのですが、あなたが AddressBook を使ってそれらを整理していることは気にしません。

あまり一般的ではない例を挙げると、AR ヒューマンには 2 つの Eye オブジェクトがあります。その人の目の色を確認できるように片方の目をあげるようにその人に依頼しますか、それともその人の目の色を直接尋ねますか?

于 2012-04-17T12:44:18.960 に答える
1

良い質問です。これは、DDDで正しく理解するのが難しいと私がいつも感じていることの1つです。常に集約ルートを介してエンティティにアクセスし、ある時点でデメテルの法則に違反する可能性がありますか（AggregateRoot.EntityX.EntityY.DoStuff（） ）？アグリゲートルートを短絡しますか？集約ルートレベルで、アクセスするサブサブエンティティごとに1つの直接アクセサーを追加し、集約ルートを混乱させますか？

これを解決する1つの方法は、すべてのオブジェクトがそのすぐ近くまたは近くの隣人とだけ話し、遠くの見知らぬ人とは話さないようにすることです。集合ルートからアクセスする最終エンティティまでのパスのごく一部をそれぞれが知っている複数のオブジェクトを使用します。

  • 最初のオブジェクトは集約ルートのみを知っています。

  • AggregateRoot.SubEntity1を2番目のオブジェクトに挿入します。

  • 次に、2番目のオブジェクトがSubEntity1.SubEntity2を3番目のオブジェクトに挿入します

  • 等々。

興味深いことに、これが明らかにすることの1つは、一部のドメインエンティティの（非）関連性です。住所の例では、会社の主要な住所にアクセスしたいすべてのオブジェクトに名簿が挿入されるのが適切かどうかを自問してください。複雑すぎると思われる場合は、そもそも名簿を持ってはいけません。結局のところ、それがユビキタス言語の一部になるに値するほど強い概念ではないかもしれません。

または、AddressBookがクライアントオブジェクトで使用するのに正確に適切なオブジェクトであり、このクライアントオブジェクトが会社と住所の両方を操作する際に一度に多くのことを実行しようとしていることがわかるかもしれません。

于 2012-04-17T11:55:59.570 に答える
1

集約パターンによると：

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

つまり、Company は Address オブジェクトへの参照を集約外の他のオブジェクトに渡すことができますが、Address を集約外の他のオブジェクトのメンバーにすることはできません。

たとえば、オブジェクト User は Company から Address への参照を要求できますが、User はそのメンバーの 1 つとして Address を持つことはできません。

そして、なぜそれがそれほど重要なのですか？

ルートはアクセスを制御するため、内部の変更によって盲目的になることはありません。

オブジェクト User がそのメンバーの 1 つとして Address を持っている場合、そのオブジェクトはその Company なしでデータベースから取り出される可能性があり、したがって、Company はその内部の変更によって不意を突かれるでしょう。

私が書いた投稿を見てください。この原則がなぜそれほど重要なのかを示しています。

于 2012-04-17T07:16:48.483 に答える