Aproach multi aggregate interaction

Hi Allard and all,

I’m looking for an approach to the interaction between 2 aggregates as example
1AR and 2AR have commands ADD and REMOVE.
Read topic i found 3 set:
1.Send command REMOVE to 1AR it generates event REMOVED->event handler catch and generates
command ADD to 2AR if exception occurred event handler generates revert command ADD to 1AR ( as singleton saga)
2.Inject 2AR reposiory in 1AR and do as UoW and publish events ADDED REMOVED after commit.
3.Make service that send command REMOVE to 1AR , ADD to 2AR if exception occurred send revert command ADD to 1AR.

First can not return exceptions for clients, second i dislike, third i like.

What aproach is better for simple application for example.

Мy suggestion:
client->serviceAPIAdapter->command handler—>AR1


serviceAPIAdapter have client api and translates it generates commands, make query for validations return exceptions etc.
For set 3 in above client invoke method on serviceAPIAdapter than service query for validations if ok send REMOVE to AR1 if ok send ADD to AR2 if exception occurred send command ADD to AR1 exception return to client.

Do I understand right approaches and what weaknesses is in my example.

Hi Evgenij,

your analysis seems correct to me.

From an API point of view, you would (regardless of the solution) have a MoveCommand. The effect is that it removes from AR1 (with a MovedOutEvent, for example, to express intent better) and adds to AR2 (with a MovedInEvent). Then, the rest becomes an implementation detail, and can be subject to change if you don’t like the solution.

Note that option 3 and the DisruptorCommandBus might not be best friends. It could be possible to get a deadlock, as the thread holding a position on the buffer needs to claim another position on that buffer, which might only become available after the first has been released.



Hi Allard,

Thanks for the reply.
I never saw a domain service in example in axon possible i bad looking for.
And for the transmission from AR1 to AR2 as REMOVE ADD I have idea to make a separate command handler as transaction service for handle command MOVE_FROM_TO and publishes START_TRANSFER event.
This event catch saga send command to AR1 REMOVE catch event from AR1 and if ok send command to AR2 ADD catch event from AR2 if ok send command to service OK or ERROR. Service publishes event MOVED_FROM_TO or ERROR_MOVED.
Is it really ok or bad idea?
And second how catch event from transfer service caller?It possible?


I am not sure if I would use a Saga for this. It’s probably easier to use a Command Handler that sends out two new commands.

If you do use a Saga, then have AR1 handle the moveCommand, and let the Saga react to the MovedEvent. The saga sends out a command to AR2, and takes action if that fails.

I would try not to wait for the entire process to complete. How big is the chance of the second command failing? Is it really worth all the development effort? /but if you really have to, you’d have to implement an Event listener that executes some logic as soon as an event comes by that matches certain criteria. In this case, you’d want to use some “transactionId” or correlationId so you know which event belongs to which transaction.



Hi Allard,
I try 3 variants and stop on UOW with injected Repository A2 in command handle A1.
This variant simple ,durable and testing.
Thanks you for time.