Hi,
I’m sorry if this question has been asked before but I couldn’t find it.
In my domain I have two aggregates order and request. Order is basically a grouping of requests. You create an order and then you create requests that are part of that order. When you submit the order the requests all become submitted and are dealt with individually. At some point every request is completed and the order becomes completed as well.
We currently solve this by having a submitOrder command that will basically load the Order aggregate and all the Requests and tell them to be submitted. I know that one could argue that you can have the Request just be properties of the Order, but they do live independently once created and are two different business concepts. A probably similar problem would be a Person and Employments.
This works fine and is an approach we used in the past when implementing a CQRS system in PHP. However the testing tools provided by axon begin to fall down. I saw the Bank example where a saga is used to deal with a transfer between two accounts, but then it would be two transactions for this one business transaction.
How would be a better approach to handle this?
Thanks in advance!
Mauricio
Hi Mauricio,
In Axon a command can only ever point to a single aggregate.
The fact that a command has the requirement of a @TargetAggregateIdentifier annotated field or function to supply the aggregate you wish to perform the action on exemplifies that.
That said, yes you could solve this with a saga which is associated to your Order aggregate and all the Request aggregates.
Your saga would then trigger on a OrderSubmittedEvent and send out subsequent SubmitRequestCommands.
Latter on that exact same saga would probably listen to the RequestCompletedEvents and once every Request aggregate is completed, the saga would send out a CompleteOrderCommand.
To be fair I’m not sure if I would regard your point of ‘two transactions for this one business transaction’ an issue in the use case you provided, as to me it sounds like a (relatively?) long running (complex) business transaction.
If you wouldn’t want to use saga’s but do want to keep the logic of applying a OrderCompletedEvent once all requests are completed, I’d guess the cleanest approach would be to let the Requests be a part of the Order Aggregate. The Order aggregate would in that case be aware of the state of all Requests and could this complete itself once it’s done.
Hope this helps!
Cheers,
Steven