CQRS + DDD +イベントソーシングでの通信を凝集します

Question

どのように分離する必要があります 総根 （AR）イベントソースの総バックエンドを使用して、DDDの原則に基づいて構築された環境で互いに通信しますか？

たとえば、私は持っています Facility の作成を担当する工場メソッドを備えた集約ルート（AR） Booking ar。 Booking aの時間に敏感な組み合わせです Person ARおよびa Facility ar。 a Person 単一でのみ予約できます Facility.

DDDでは、私は Booking の Person, 、 と Person の Facility. 。ただし、イベントスーリングで使用するためのイベントを生成する場合、バックエンドからのイベントの脱皮化を処理しようとすると、禁止されると思います。したがって、私は値オブジェクトベースの一意のIDへの参照のみを保持することにしました。ただし、これにより、ARのメソッドが別のARの別の方法を呼び出す必要がある場合、新しい問題が発生します。その状況をどのように処理しますか？ドメインARからイベントソースリポジトリを押しますか？

このシナリオの一般的なユースケースは何ですか？私はこれをすべて間違っていますか？

Answer 1

集計ルート境界は、一貫性の境界を定義します。集計内では、一貫性が保証されます。外は...そうではありません。したがって、いくつかの集合体にまたがって一貫性を持たなければならない操作はありません。 2つの集計にまたがるトランザクションが必要な場合は、集約境界を確認する必要があります。

アグリゲートの外で発生することについては、他の集計にコマンドを送信するイベントハンドラーが必要です。集合体間のアクションの論理がより複雑な場合、イベントを聞き、コマンドを集計に送信するステートマシンであるプロセスを定義できます。プロセスを使用して、長い実行トランザクション（ロールバックの代わりに補償を使用して）を定義したり、システムで何が起こっているかに基づいてビジネス上の決定を下します（境界のあるコンテキストの間でも）。

Answer 2

イベントソーシングとCQRSを使用する場合、AR間コミュニケーションの最もエレガントな（少なくとも私の意見では）方法はメッセージングです。あなたは見ることができます NCQRS プロジェクト（あなたが.NETの男である場合は簡単になります）、特に「メッセージング」ブランチ。アイデアは、ARSが処理するメッセージタイプごとにImessageHandlerインターフェイスを実装し、AR Baseクラスはメッセージを送信するためにメソッドを公開することです。このAPIによって、クライアントはモデルの動作を呼び出し、モデル自体が通信することができます（ARの間）。