0

現在、システム内のエンティティ、値オブジェクト、および集計を決定しています。次のエンティティが特定されたとします。

顧客、CustomerEmail、電子メール、CustomerAddress、住所、AddressType

ここで、Customers -> Emails は多対多の関係であり、Customers -> Addresses (アドレス タイプを使用) と同様です。これらの関係は、CustomerAddress および CustomerEmail 関係オブジェクトによって表されます。

最初は、これは簡単だと思いました：

エンティティ: Customer、CustomerEmail、CustomerAddress 値オブジェクト: Email、Address、AddressType

Customer は、上記のすべてのエンティティと VO を含む集約の集約ルートです。

私が抱えている問題 (そして、これは、先に進むにつれて集計の概念について学習しているだけかもしれません) 同じ Address および Email 値オブジェクトを使用して、上記の Customer 集計を反映する Supplier エンティティがあるとします。この場合、顧客が削除されても、アドレスと電子メールは削除されるべきではありません。サプライヤーとして、または別の顧客でさえもそれらを参照している可能性があるからです。集約が削除されると、集約境界内のすべてが一度に削除されることを示唆する多くのドキュメントを見てきました。これが集合体の値オブジェクトには適用されないと仮定するのは正しいですか (つまり、それらは不変です...車両集合体に緑色の色オブジェクトがあった場合...車だからといって色を削除することはありません)または、電子メールとアドレスが 2 つのアドレスとして独自のエンティティ (および集合体) である必要があります。

最後に、それらが実際に値オブジェクトである場合、VO が集約ルートを介してのみ作用できる場合、それらを削除する必要がある場合 (アドレスを参照しているサプライヤーまたは顧客が残っていない) をどのように処理しますか?

乾杯、

スティーブ

4

1 に答える 1

2

あなたはあなたのデータベースのサームであなたのドメインについて考えています。これはお勧めしません。

上記の顧客集計を反映するサプライヤーエンティティ

これは、ドメインに概念がないことを示しています。この「ミラーリング」は、ドメインエキスパートにとってどのような意味がありますか？実際にそれらの間に関係がある場合は、明示的にモデル化する必要があります。

あなたは「顧客->電子メールは多対多の関係です」と言います。メールが複数の顧客によって共有されることは、ドメインにとって意味がありますか？はいの場合も、おそらく概念が欠けています。ドメインの専門家がこの関係について何と言っているかを確認してください。それが実際には多対多ではなく、多分1対多である場合、電子メールは顧客エンティティが「所有する」値オブジェクトです。これで、顧客が電子メールまたはアドレスを所有している場合、制限なしでそれを削除（またはそれに基づいて行動）できます。

DDDの最も難しい点の1つは、常にアグリゲート間でエンティティを共有しようとすることです。しないでください。骨材の穴のポイント、つまり一貫性の境界を打ち負かします。代わりに、ドメインエキスパートの助けを借りて、AR間の境界を明確にする欠落している概念を特定します。

私はそれがすべて抽象的なように聞こえることを知っています（私は過去にこのような質問をしました）が、真実はあなたのドメインの専門家だけがあなたがドメインをより良くモデル化するのを助けることができるということです。

そして最後のアドバイスとして-EricEvansの本を再（-re X 100）読むことは通常役に立ちます:)

于 2011-05-05T07:48:58.627 に答える