Question

How should separate aggregate roots (AR) communicate with one another in an environment built on DDD principles using an event-sourced aggregate back-end?

For instance, I have a Facility aggregate root (AR) which has a factory method responsible for creating a Booking AR. The Booking is a time-sensitive combination of a Person AR and a Facility AR. A Person can only be booked in a single Facility.

In DDD, I would have held references to the Booking in Person, and Person in Facility. However, when generating events for use in event-sourcing I think that trying to handle the event deserialization from the back-end would become prohibitive. Therefore, I ve taken to only holding references to the value object-based unique id s. This brings up a new problem, however, when a method on an AR needs to call another method on another AR -- how do you handle that situation? Hit the event source repository from the domain AR?

What is the general use case in this scenario? Am I approaching this all wrong?

Answer 1

Aggregate Root boundaries define a consistency boundary. Inside the aggregate, consistency is guaranteed. Outside... it s not. So you should not have operations that spans several aggregates and have to be consistent. If you need a transaction that spans two aggregates, you should review your aggregate boundaries.

For things that happen outside the aggregate you should have an event handler that will send a command to other aggregates. If the logic of actions between aggregates is more complicated, you can define a process, a state machine that will listen to events and send commands to aggregates. Processes can be used to define long running transactions (with compensation instead of rollback), or take business decisions based on what s happening in the system at a large scale (even between bounded contexts).

Answer 2

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).

友情链接