ドメイン駆動設計におけるWord集計の意味に関する混乱
ドメイン主導の設計についての議論の中で、Word aggregate を使用すると、さまざまな人々がさまざまなことを考えるように見えることを学びました。主な問題は、他の人が aggregate type と呼ぶものにWord aggregate を使用する人がいることです。
同じ言葉でも意味が違うと話し合うのはなかなか難しい。このため、ほとんどの人と文学が同意することを明確にしようと試みました。この質問に答えていただければ、文献の参照をいただければ幸いです。
1人の場合、集合体はエンティティのコレクションをグループ化する境界です。より概念的なクラスタリング境界です。
別の人にとって、集合体はデータベースリポジトリから転送されたエンティティのコレクションです（移行の一貫性があります）。つまり、集合体は単なる概念ではなく、現実的なものです。たとえば、データベースから2人のユーザーを読み込んだ場合、同じ種類の集計の2つの集計を読み込みました。
トランザクションの同意であるエンティティのコレクションであると考えているが、特定の集約タイプのデータをロードすると、一部のデータ（たとえば、一部のデータはnullのみ）をロードして、全体を1つの集約として呼び出すこともできると考える別の人他の人はこれを2つのアグリゲートと見なします（最終的な整合性とは、両方のアグリゲートが保存された後に整合性が与えられることを意味します）。
私自身、Word集計の真の意味を見つけるために、Martin Fowlerの definition を調べました。ここでは、集約は実際のものであり、同じ集約タイプの2つの集約が存在する可能性があります。しかし、 Vaughn Vernonのこの記事を読んだときaggregateが '解釈された理解のようなMartin Folwer'はaggregate typeと呼ばれるべきです。
ドメイン駆動設計の用語については、エリックエバンスによる「ブルーブック」- ドメイン駆動設計 から始めます。
[〜＃〜] aggregate [〜＃〜]データ変更の目的で1つの単位として扱われる関連オブジェクトのクラスター。外部参照は、ルートとして指定された集約の1つのメンバーに制限されます。集合の境界内で一連の整合性ルールが適用されます。
その最後の文、私はあなたが好転することができると思います-集計の境界は一貫性ルールによって定義されます。
集合体に状態があるのは間違いありません。ドメインモデルが変更されるたびに、一貫性のある状態から別の状態に集約が取得されます。保持するデータは、この状態を再構築するために使用されます。その意味で、それは本物です。
しかし、集合体自体がユビキタス言語のWordを持っているとは限りません。それは派生した概念です。
おおまかに言って、ドメインモデル全体を単一の集約の下に置くことができ、これによりすべての整合性ルールが適用されます。なぜなら、その設計はスケーリングしないためです。ドメインモデルを2つの異なる方法で同時に変更することはできません。たとえ、行っている変更が一貫性のルールを共有していない場合でもです。一度に複数のことを行うことができるビジネスをモデル化するには、これは不適切な方法です。
代わりに、一貫性ルールをセットに分解します。同じデータを参照する2つのルールは同じセットの一部でなければならないという制約に従います。 （これを行う際に、ユビキタス言語とドメイン専門家と協力して、整合性ルールを正しく記述しているかどうかを判断します）。
モデルを更新するために、データの一部である集計を特定し、変更を提案します。アグリゲートがすべてのローカル整合性ルールを検証すると、変更はグローバルに有効であることがわかり、変更を適用できます。これにより、一度に複数のことを実行できるようになります。異なる集合体のデータへの変更は、構造上、互いに競合する可能性はありません。
ベストプラクティスでは、ほとんどの集計にはルートエンティティのみを含めることをお勧めします。したがって、あまりリスクをかけずに、集合体をエンティティーと融合できます。しかし、それが複数のエンティティーを含む場合、クラスターにぶら下がるユビキタス言語には通常何もないでしょう。つまり、ShoppingCart集計と、ShoppingCartエンティティおよびCartItemsエンティティコレクションの整合性ルールを維持することになります。
変更を適用しようとすると、アグリゲートの部分的な読み込みが失敗します-適切に設計されたアグリゲートが、データのサブセットを使用してその整合性ルールのすべてを検証できるのはなぜですかこれが理にかなっている要件がある場合、モデリングがどこかで壊れているのは確かです。
ただし、読み取りを行っている場合は、アグリゲートによって保護されているデータの一部のみをロードするのが理にかなっています。 Command Query Responsibility Separation（CQRS）は、これをさらに一歩進めます。モデルがデータが整合性ルールを満たしていることを確認したら、そのデータを読み取り専用の形式に完全に再配置して、最も使いやすい形式にすることができます。言い換えると、データの変更に関心がない場合は、集計の境界をまったく気にする必要はありません。
DDDには「データベース」や「トランザクション」はありません。 DDDは、データベース、トランザクション、または「結果整合性」に完全に依存しません。したがって、それらを含む定義はDDDでは無効です。
それは基本的にあなたの拳の定義だけを残します。私が感じるのは正しいものです。
また、Martin Fowlerの説明が最初の定義以外の何かに当てはまると感じる方法もわかりません。
しかし、「実用的なDDD」について考えると、混乱がいかに忍び寄るかがわかります。つまり、DDD +インフラストラクチャがその上に構築されます。たとえば、データベースの一部だけで作業している場合、データベースから全体の集計を具体化することは意味がないかもしれません。しかし、それでは、アグリゲートが本当に適切に設計されているかどうか疑問に思います。多分それは複数の集合体に分割されるべきです。いずれにせよ、インフラストラクチャを導入し始めると、DDDの概念ではなくなり、別の概念になります。あなたができる唯一のことは、これを実現し、チームの全員が「集合体」の意味とそれが持つ特性に同意することです。名前は効率的なコミュニケーションのために重要です。また、チームとのコミュニケーションは、外部とのコミュニケーションよりも優先されます。
ヴォーンが「基幹業務」スタイルのソフトウェアにおけるモノリシックな集合体のルーツの実際的な問題に苦しんでいるように私には思えます。
マーティンがモノリシックを好むところOOPソフトウェア。これは、プロセス全体をメモリに収めることができるときにうまく機能します。
しかし、両者に矛盾はないと思います。ドメインオブジェクトをDDDのコンテキストと集計に分割する場所を選択する必要があります。一方で、実生活のプロセス全体を網羅する集約ルートが必要です。他方、これらが大きくなりすぎると、実際的な問題が発生するため、それらを少し小さく分割して、ドメインイベントまたはその他と結合する必要がある場合があります。策略