12

2 つの集約ルートと 2 つの非集約ルート エンティティがあります。

エンティティ関係

私は、関係がD -> BDDDの原則に違反していることを知っています。

ほとんどの場合、解決策は参照されたエンティティを新しい集約ルートにすることだと聞きました。

しかし、 B が A の本当の子である場合(B は A なしでは生きられない) 、B を新しい集約ルートにするオプションは本当にあるのでしょうか?

4

2 に答える 2

2

私はあなたに同意します.1つのエンティティをその集合体から分離することが意味をなさない場合があります. これが、一部の人が推奨する「小さな集計」アプローチに私が完全に納得していない理由の 1 つです。

このような場合にできることは、直接取得するのではなく、A のインスタンスを走査して B への参照を取得することです。結局のところ、B が​​ A なしでは存在できないのであれば、集合体の外部にあるオブジェクトが特定の B について知っていて、その A について知らないという理由はありません。

于 2012-11-15T13:08:00.123 に答える
1

まず第一に、これは DDD の考え方ではなく、RDBMS の考え方です。DDD では、ビジネス プロセスを現実世界と同じようにモデル化します。1 対多などの概念はありません。したがって、DB、外部キーなどは忘れてください。

境界付けられたコンテキスト (BC) は何ですか? 各集合体は BC そのものであるため、同じ名前が付けられていても概念の異なる表現を持つことができます。

正しく理解すれば、ABCD は 1 つの集合体の一部のようです。それは、それらがその集約でのみ、その形式でのみ定義されるという意味ではありません。ただし、C が他の BC の本格的な AR である場合、このコンテキストでは id またはいくつかのプロパティとしてのみ表現される可能性が非常に高くなります (インターフェイスはこのようなものに非常に便利です)。したがって、両方とも C という名前であっても、特定のコンテキストで必要な動作のみを備えており、異なります。

DDD は多くの BC で動作し、モデルは 1 つの BC に対してのみ有効です。つまり、アプリでは、各 BC に従って複数の A 、B 、C 定義があり、各定義がわずかに異なる可能性があります。つまり、すべてのケースに適したモデルは 1 つだけというわけではありません (ここでは CQRS について話しているのではなく、DDD について話しているだけです)。

より具体的なものを実際に思いつくためのドメインについてはあまり知りません。しかし、簡単に言えば、物事をありのままに表現し、実際に機能するようにしてください。

于 2012-11-17T11:18:56.327 に答える