ドメイン イベント パターンとこの投稿を考慮して、トランザクション モデルごとに 1 つの集計を保持することを人々が推奨するのはなぜでしょうか? 1 つの集計が別の集計の状態を変更できる場合があります。集約を削除 (またはその ID を変更) しても、それを参照する他の集約の状態が変更されます。集約ごとに 1 つのトランザクションを維持するとスケーラビリティーが向上する (サーバーごとに 1 つの集約を維持する) と言う人もいます。しかし、この種の考え方は、DDD の基本的な特徴であるテクノロジにとらわれないという特徴を壊しているのではないでしょうか。
したがって、上記のステートメントとあなたの経験に基づいて、他の集計の変更につながる集計、ドメインイベントを設計するのは悪いことですか?これにより、トランザクションごとに2つ以上の集計が行われます(例: 新しい注文が行われたとき) 100 個のアイテムを使用すると、顧客の状態が通常から VIP に変わります)?
集約は関連するビジネス オブジェクトをグループ化し、集約ルート(AR) はその集約の「代表」です。AR 自体は、(より大きく、より複雑な) ドメイン概念をモデル化するエンティティです。DDD では、モデルは常にコンテキスト (境界付けられたコンテキスト - BC) に対して相対的です。つまり、そのモデルはその BC でのみ有効です。
これにより、特定のビジネス コンテキストを表すモデルを定義でき、すべてを 1 つのモデルだけに押し込む必要はありません。Orderは、あるコンテキストでは AR ですが、別のコンテキストでは単なる ID です。
AR はすべての下位概念とビジネス ルールをほとんどカプセル化するため、全体として、つまりトランザクション/作業単位として機能します。1) リポジトリは常にビジネス オブジェクトを処理し、2) AR は特定のコンテキストのビジネス オブジェクトを表すため、リポジトリは常に AR と連携します。
2 つ以上の AR を含むユース ケースがある場合、ビジネス ワークフローとそのユース ケースの正しいモデリングが最も重要です。多くの場合、これらの AR は個別に変更することができます (他のものは気にしません)。または、他の AR の動作の結果として ARが変更されます。
あなたの例では、それはかなり簡単です: 顧客が 100 個のアイテムを注文すると、ドメイン イベントが生成されて公開されます。次に、注文がカスタマー プロモーション ルールに準拠しているかどうかを確認するハンドラーがあり、準拠している場合は、クライアントの状態を VIP に変更するコマンドが発行されます。
ドメイン イベントは非常に強力で、結果整合性のある環境でトランザクションを実装できます。古い db トランザクションは実装の詳細であり、通常は 1 つの AR を永続化するときに使用されます (AR は論理ユニットとして扱われますが、永続化には複数のテーブルが含まれるため、db トランザクションが含まれる場合があることに注意してください)。
結果整合性は、豊富なドメイン (そして現実の世界) に自然に適合するドメイン イベントの「機能」です。場合によっては、即時の一貫性が必要になる場合がありますが、これらは特定のケースであり、ドメインの動作ではなく UI に関連しています。もちろん、ドメインによって異なります。あなたの例では、顧客は、同じミリ秒ではなく、注文が行われてから 2 秒または 2 分後に VIP になったことを気にしません。