2

私は DDD で小さなプロジェクトに取り組んでいます。値オブジェクトは immutableであるため、変更できません。エンティティのみ。

誰もが使っている例を使用します。住所。Address がCustomer エンティティの VO であるとしましょう(これはルート集約でもあります)。ユーザーが自分の Address を更新した場合、これはショッピング カートのどのシナリオでも有効ですが、どうすればよいでしょうか? データベースに保存するには、VO アドレスを変更する必要があります。つまり、データベースで識別できるようにするには、この VO に ID が必要です。NHibernate がマッピングを使用して処理しない限り、そうです。LinqToSql の場合はそうではありません。または、代わりに Address がエンティティである新しい Aggregate を作成する必要があると思いますか? 次に、集計でアドレスが必要な場所にアドレスのコピーがほとんどありますか?

でも。私はまだエンティティ/VO の概念全体をラップすることはできません。DB に表現を持つものはすべて、モデルで VO として使用する場合でも、何らかの形でエンティティであるように思えます。それを永続化するには、データベースでそれを識別するために何らかのキーが必要だからです。 .

結局のところ、すべての値オブジェクトのデータは (ほとんどの場合) データベースから取得されます。そのため、そのデータが更新された場合にそれらを不変にする方法をまだ理解できません。

2 か月間熱心に読んだ後、DDD 全体が巨大な矛盾の問題であることがわかりました。これらのブログをすべて読むと、私が話していることがわかります。残念ながら、ロールモデルやガイダンスとして使用できるデモアプリケーションはゼロです. それらはすべて、開発者の好みに大きく影響されます。その後、彼らはお互いのブログを攻撃することになります。Overnight-DDD-Guru のブログは、コミュニティ全体の混乱を助長しています。

お立ち寄りいただきありがとうございます。建設的な議論を期待しています。

4

4 に答える 4

8

あなたの混乱は、データベースの行 ID と DDD のエンティティに関連付けられた ID の概念との間の人為的な結合にあると思います。エンティティには、データベースで ID 列として表される対応する ID があるため、それらは確かに関連しています。ただし、何かがデータベースの行として ID を持っているからといって、そのオブジェクトが DDD の意味で ID を持っているとは限りません。

住所の例では、住所 VO を構成する値は通常、顧客エンティティと同じ行に格納されます。このように、アドレスは独自の行に格納されず、ID を持たないため、値オブジェクトです。住所を更新すると、顧客エンティティの住所プロパティの値が変更され、データベース行に反映されます。

値オブジェクトが独自の行に格納される場合があります。たとえば、ステレオタイプの販売注文モデルでは、注文はエンティティ (集約ルート) であり、品目は値オブジェクトです。項目は VO ですが、リレーショナル モデルでは、それらは独自のテーブルに格納され、主キーを持つ可能性が非常に高くなります。ただし、ドメイン モデルでは、VO は注文エンティティに関連付けられており、そのエンティティの外部に ID はありません。

于 2012-11-20T03:15:22.660 に答える
3

実際、Javaのオリジナルの DDDSample を始めとして、おそらくあなたが想像するすべてのテクノロジで、たくさんのデモがあります。このサンプルには、少なくとも 2 つの .NET ポートがあります: NDDDとDDDSample.Netです。

VO と永続性については、エンティティを表すテーブルからいくつかの列をラップするオブジェクトとして VO を考えると、簡単ではありません (例: Money VO ラップの金額と通貨)。問題は、SQL レベルでデータを正規化し、VO のテーブルを作成する場合に始まります (エンティティ テーブルに埋め込むのではなく)。この問題の適切な解決策はわかりませんが、幸いなことに、リレーショナル ストレージを使用して DDD を実装する場合は、適切な方法ではありません。なんで？最も重要な原則の 1 つは、集計は可能な限り互いに独立している必要があるということです。オブジェクト モデルでVOクラスを共有することはこのルールで問題ありませんが、データ ストレージで VOテーブルを共有することはできません。たとえば、この単一のテーブルがロックのボトルネックになる可能性があるためです。

つまり、SQL データベースを使用してドメイン モデルを格納する場合は、集計間でモデルを正規化しないことを検討してください。

于 2012-11-17T06:43:08.500 に答える
2

また、現実世界 (またはドメイン) の観点からそのような問題を調べてみることもできます。住所が変わることはめったにありません。住所自体が変更されるよりも、顧客が住所を変更する (たとえば、別のフラットに移動する) 方が一般的です。

これを念頭に置いて、アドレスは値オブジェクトでなければなりません。

于 2013-05-21T12:33:57.203 に答える
0

ねえ、これは本当に古い質問だと思いますが、私は DDD クエストに参加しており、同様のクエリがいくつかありました。

私が DDD で見つけた解決策への最善の方法は、DB のことは忘れて、モデルについて考えることです。上記の状況では、Customer と Address VO があり、顧客の Addresses のリストが必要です。たとえば、顧客が複数の配送先住所を選択できる e コマース サイトのシナリオです。ドメイン モデルの真のコンテキストでは、これらのアドレスは単なる Address VO ではなく、CustomerShippingAddress エンティティです。

したがって、CustomerShippingAddress エンティティには ID があり、Address VO があります。たぶん、IsDefault や DateAdded などのような他のものがあるかもしれません

Address VO を渡す Customer エンティティからのみ CustomerShippingAddress をインスタンス化し、顧客への ID 参照を保持する CustomerShippingAddress の集約ルートを取得することをお勧めします。

このようにして AddressVO を維持しますが、その VO を複数のシナリオで再利用できます。

顧客が注文の配送先住所として住所を選択すると、顧客が選択した AddressVO が注文集計に適用されます。これは、その注文の配送先住所が、その時点で住所 VO に間に合うようにロックされていることを意味します。CustomerShippingAddress は後で変更される可能性がありますが、配送先住所 VO は注文で永久に同じままです。

于 2016-03-17T13:37:40.993 に答える