web-dev-qa-db-ja.com

他の複数の集約ルートによって作成される集約ルート

タイトルが紛らわしいことは知っていますが、言葉で表す方法はありませんでした。

私はドメインドリブンデザイン（DDD）を研究していて、Microsoftから「コンテナ化されたNETアプリケーションのためのNETマイクロサービスアーキテクチャ」という本を読んでいます。

この本では、Orderが集約ルートでOrderItemが子エンティティである例を使用しています： Order aggregate example

私がそれを正しく理解している場合、誤っていない場合、別の集約ルートである必要がある製品を識別するProductIdがOrderItemにあります（本で提供されている source には、Product Aggregateがなく、製品はモデルに存在しませんが、単純化するためだと思います）。

ここで、OrderItemが参照するAggregate Root TaxesDetailがあり、このTaxesDetailに、商品の税金と、buyerIDの税金、およびOrde​​rItemの作成時に他のいくつかの値が追加されていると想定して、問題を明らかにします。 OrderItemのみがTaxesDetailを作成できる場合、TaxesDetailは単純に子エンティティになりますが、OffersItem（OrderItemとは異なるいくつかのフィールドを持つ）を提供するオファーの集約ルートがあり、次にTaxesDetailを持っている場合、TaxesDetail ？ AggregateRoot？子エンティティ？子エンティティの場合は、コードを複製するOrderTaxesDetailとOfferTaxesDetailを作成する必要があります。

これは一例にすぎませんが、私が理解しようとしているのは、複数の集約ルートが同じ集約ルートを作成できる可能性がある場合に、集約ルートの概念、1つを識別する方法です。

ありがとう

[〜＃〜]編集[〜＃〜]

コメントは長すぎないため、@ Christopheに返信するための編集。

IDの場合、OrderDetailを変更して古いTaxesDetailを削除し、新しいTaxesDetailを作成するだけでよいと思います。古いTaxesDetailを追跡する必要はないと思います。

これが値オブジェクトであることがわかります。最初の点では、lifespanがOrderDetailとOfferDetailの集約ルートに完全に依存していることがわかります。 2番目の点では、immutableであることがわかります。たとえば、変更されたOrderDetail、TaxesDetailが変更されない場合、TaxesDetailは破棄され、新しいプロパティで構築されます。

実装の考慮事項とモデルの構築方法を念頭に置いていたとおっしゃったように、ドメインアプローチから設計を開始するのではなく、ドメインレイヤーと永続性レイヤーを混在させていました。次回はもっと注意を払う必要があります。

ご協力いただきありがとうございます！

architecturedomain-driven-designaggregateentity
1
mmas

まず最初に

orderItemが参照するAggregate Root TaxesDetailがあるとします。

まず、深く理解してください。TaxesDetailが最初から集約ルートになる可能性があると思われる理由は何ですか。そして、集合体は何でしょうか？

OrderItemのみがTaxesDetailを作成できる場合、TaxesDetailは単純に子エンティティになりますが、OffersItem（OrderItemとは異なるいくつかのフィールドを持つ）を提供するオファーの集約ルートがあり、次にTaxesDetailを持っている場合、TaxesDetail ？

どうしてそれをagretate rootにすべきなのですか？税の詳細は何ですか？そもそも税務詳細にはアイデンティティがありますか？

DDDの基本的な概念

エヴァンの独創的なDDDブックの3つのコア定義を見てみましょう。

[〜＃〜] aggregate [〜＃〜]：データ変更の目的で1つの単位として扱われる関連オブジェクトのクラスター。外部参照は、ルートとして指定されたAGGREGATEの1つのメンバーに制限されます。一連の整合性ルールがAGGREGATEの境界内に適用されます。

TaxesDetailは、関連するOrderDetailまたはOfferDetailとは別に変更されますか？または、TaxeDetails整合性ルールは、既に別の集合体にある他のものに関連していませんか？正直なところ、これが集約ルートになる可能性があることを真剣に疑っています。

[〜＃〜] entity [〜＃〜]：基本的には属性ではなく、連続性と同一性のスレッドによって定義されるオブジェクト。

TaxesDetailには独自のIDがありますか？または別の方法で尋ねられました：OrderDetailを変更するとします：古いTaxesDetailを削除して新しい値で新しいものを作成できますか、それとも古いTaxesDetailを追跡してその属性を変更することが重要ですか？

VALUE OBJECT：いくつかの特性または属性を説明するが、アイデンティティの概念を持たないオブジェクト。

それで、結局のところTaxesDetailは何ですか？税コード（料金を定義する）とアイテムに対して計算される税額だけですか？この場合は、TaxCodeを参照する値オブジェクトになります。ただし、履歴を保持する必要がある場合は、Order集合体のエンティティである可能性があります。

助言

DDDはDOMAINで始まります。そして、そうする必要があります。ドメインアプローチから設計を開始します。実装に関する考慮事項や再利用に惑わされないでください。

  • ここでは、TaxesDetailは、OrderItemと同様に、OfferItemにも関連していると見なして誤解を招きました。実際、同じものであると仮定して、実装の観点から類似点を確認します。

  • しかし、ビジネスの観点からドメインを見ると、オファーの税の詳細は純粋に仮想です。オファーが順序どおりに変換されることを保証するものは何もないため、税金の支払い期限はありません。この段階では、計算された値のみです。

  • その後、注文が通過すると、確認された取引があるため、管轄区域によっては税項目が問題になり始める可能性があります。 VATのような税金を徴収する場合でも、納税項目を納税義務項目にするイベントが配達または支払いのいずれかで最も早いので、注文税は引き続き表示値になります。

したがって、結論として、実装の考慮事項とは無関係にオブジェクトを調べます。オブジェクトにIDがあるかどうかを確認し、集約ルートのクラスタリングのみを確認します。その後でのみ、どこにどのメソッドとプロパティを配置するかの詳細を入力する必要があります。

1
Christophe