Communication between aggregate roots

Jun 15, 2010 at 1:35 AM

I am trying to understand what the proper approach for communicating between aggregate roots is and I am curious what other people's opinions are on this. 

As I understand it, one aggregate root can references another via the EventSourceId however I am unsure of the best way to handle the situation when an operation on one AggregateRoot will potentially result in changes to another.  I have some possible ideas but I would like to hear other people's ideas first.

I am currently working on a solution, but at the moment, all I can think of is to have the command handler make the changes to each AggRoot in turn.  This feels wrong to me as it seems to muddy the relationship between the roots.  The DDD book suggestions that "DomainServices" handle this co-ordination, but what should be calling the domain service?

Jun 15, 2010 at 8:29 AM
chnicola wrote:

As I understand it, one aggregate root can references another via the EventSourceId however I am unsure of the best way to handle the situation when an operation on one AggregateRoot will potentially result in changes to another.  I have some possible ideas but I would like to hear other people's ideas first.

My impression is: Do the operations need to happen in the same transaction scope?

If so, they should be done by the service/handler (the operation results in two commands, affecting two aggregate roots)

If not, then the handler should execute one command, generate the appropriate events, and have the second aggregate root be changed based on listening and acting on that/those events.

Jun 15, 2010 at 8:35 AM
chnicola wrote:

I am currently working on a solution, but at the moment, all I can think of is to have the command handler make the changes to each AggRoot in turn.  This feels wrong to me as it seems to muddy the relationship between the roots.  The DDD book suggestions that "DomainServices" handle this co-ordination, but what should be calling the domain service?

I was under the impression that a single command handler should strictly only carry out the required changes to apply the one command it is responsible for to the (one) target aggregate root?

My current approach is to have the ApplicationService layer create the two commands and dispatch them to the ICommandService as required. I prefer doing this in the ApplicationService layer instead of the DomainService layer because I don't like the idea of a DomainService knowing about command dispatching. Though I think either layer could work.

I'm not entirely certain either whether this is the correct or preferred approach, so any feedback is greatly appreciated :)

Jun 15, 2010 at 5:06 PM

Yes that sounds right to me, two commands. I am not going to lie, I am not really even using the command pattern at the moment.  I am just manipulating the domain within the service calls.  Later I will extract that logic into specific commands.

 

Jun 15, 2010 at 8:06 PM

An interesting constraint on this scenario is whether or not the second command requires some kind of data or response based on the first command.

Since command executors do not (should not, according to Pieter) return values, the only way to access the results of the first command would be via an event handler on the resulting event (of the first command).

In any case, I'm really liking the event-centric domain so far. There's so much more clarity in the business process :)