26

イベントソースの集約バックエンドを使用して、DDD 原則に基づいて構築された環境で、個別の集約ルート(AR) が互いにどのように通信する必要がありますか?

たとえばFacility、AR の作成を担当するファクトリ メソッドを持つ集約ルート (AR) がありBookingます。はBooking、時間に依存するPersonAR と ARの組み合わせですFacility。APersonは単品でのみ予約可能Facilityです。

BookingDDD では、 inPersonとPersoninへの参照を保持していたでしょうFacility。ただし、イベント ソーシングで使用するイベントを生成する場合、バックエンドからイベントの逆シリアル化を処理しようとすると、法外になると思います。したがって、値オブジェクトベースの一意の ID への参照のみを保持することにしました。ただし、AR のメソッドが別の AR の別のメソッドを呼び出す必要がある場合、これは新しい問題を引き起こします。その状況をどのように処理しますか? ドメイン AR からイベント ソース リポジトリにアクセスしますか?

このシナリオの一般的な使用例は何ですか? 私はこれにすべて間違って近づいていますか？

4

2 に答える 2

46

集約ルート境界は、整合性境界を定義します。集約内では、一貫性が保証されます。外では…違います。したがって、複数の集約にまたがる操作を行うべきではなく、一貫性を保つ必要があります。2 つの集計にまたがるトランザクションが必要な場合は、集計の境界を確認する必要があります。

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

于 2010-11-03T09:12:34.103 に答える
4

When using Event Sourcing and CQRS the most elegant (at least in my opinion) way of inter-AR communication is messaging. You can look at Ncqrs project (it will be easier if you are a .NET guy), particularly 'Messaging' branch. The idea is, ARs implement IMessageHandler interface for every message type they handle and AR base class exposes method Send for sending there messages. By means of this API clients can invoke model behavior and model itself can communicate (between ARs).

于 2010-07-01T22:37:03.683 に答える