10

私は現在DDDを掘り下げており、少し啓発が必要です。

私は2つのエンティティを持っています

  • Temple
  • TempleVariant

Temple(イヤホン) には基本情報(名前、説明など) が含まれ、技術的な説明(CAD 図面、サイズなど) を持つ n 個のバリアントがあります。

私の第一印象は次のとおりでした: TempleそしてTempleVariant集合体を形成します - それらは一緒に属します: それらは非常に密接に結合しているようです

  • Templea allを削除すると、同様TempleVariantに削除する必要があります
  • TempleVariantsなしでは存在できません Temple(少なくとも意味がありません)

しかし、集約ルートの外側では、別の集約内のエンティティを参照することは許可されていないことを読みました。しかし、実際には外部エンティティによって参照されるのではなくTempleTempleVariants、 .

これは、(DDD) 現実ではTempleとTempleVariantが異なる集合体であり、集合体のように見えることを意味しますか?

しかし、その後、削除するとどうなりTempleますか? 私が言ったように、TempleVariants も削除する必要があります。しかし、それは「1つの集計変更-1つのトランザクション」(またはそれが呼ばれるもの:))というルールに違反します。なぜなら、私の「感覚」は、1つのトランザクションでそれらを削除する必要があるからです...

だから私の質問は：

  • それらの2つの集合体ですか？
  • もしそうなら：削除を処理する方法は？

ラグワラッパー
_

4

2 に答える 2

4

ドメイン モデルの各クラスは、ドメインの専門家から学ぶユビキタス言語をマッピングする必要があります。ところで、これは非常に興味深いドメインに見えます。

私には、あなたの懸念に対処するための明確な道が 2 つあります。

ビジネスの不変性を確保するには集計が必要であることを覚えておく必要があります。つまり、状態を変更するコマンドを受け取り、(適切な例外を通じて) 無効な操作を回避する責任があります。多くの場合、それらは ID を保持しているためエンティティです。

TempleVariants 値オブジェクトとして

ビジネス ルールを処理するために TempleVariant のインスタンスが必要な場合 (その場合にのみ)、それらは集約の一部である必要があります。つまり、Templeにそれらが含まれています。
ただし、それらは不変オブジェクトである必要があります。Temple状態を変更するコマンドを受け取ることができるのは (常に全体として) だけです。

この場合、Temple を削除すると、接続されているすべての TempleVariants が消えます。それでも、私が開発したほとんどの DDD アプリケーションでは、エンティティが削除されることはありません。エンティティはアーカイブされるだけです。しかし、私は金融アプリケーションとドメインに慣れています。あなたのドメインでは寺院を削除するのが正しいことかもしれません。

TempleVariantDTO としての s

Templeビジネス ルールを確保するために必要なコマンドがない場合TempleVariant、文字はおそらく、DB スキーマをマッピングする適切な DTO で処理できる有用な記述データです。この場合、指定された のすべてのバリアントを返すインフラストラクチャ サービスを定義しますTemple。

この場合、DTOで関連の共有識別子Templeを公開できますが、必須ではありません。

集合体設計の詳細については、Vernon の集合体設計に関するエッセイを読むことを強くお勧めします。

于 2013-04-15T09:20:14.953 に答える
0

違反したルールと「現実世界」での行動に関する MikeSW の質問により、私は自分のアプローチを再考しました。ドメインの専門家と話し合った後、私のアプローチが domain と一致しないため、ddd に違反していることに気付きました。現在、モデルを再設計しています。

@Question:モデルにTempleVariantsを残した場合、バリアントを参照する可能性を持たせるために、「 identity-relative-to-parent-to-parent」アプローチを使用していたでしょう (MattDavey が示唆したように)。しかし、設計上のより重要なエラーは依然として存在します。Temple

基本設計が正しければ、両方の集計ルートを個別に作成していたはずです。それは（私の観点からは）機能していたでしょうが、設計エラーをカバーしていたでしょう（少なくとも私の場合）。

一般的に、ddd ルールに違反している場合は、一歩下がって実際のビジネスを見直し、ドメインと本当に一致するものがあるかどうかを確認することをお勧めします。

ご協力ありがとうございました！

于 2013-04-15T14:02:57.077 に答える