Hi all,
Let's say there's an Order AR that holds reference to Customer entity
which is an AR by itself. If one day there's a need to change
Customer's name, address, email etc through Customer AR, how do we
synchronize it with Customer reference in Order AR ?
Any advice would be greatly appreciated.
Thanks & Regards,
Setya
Hi Setya,
An aggregate should never directly reference any entity outside of that aggregate. The only type of reference allowed is by identifier.
If an activity in one aggregate should result in a modification of another, you should ask yourself this question first: aren’t these supposed to be inside the same aggregate? The answer to that question depends on the consistency requirements that these changes have.
If they are really two separate aggregates, you should create an Event Listener or better, a Saga (but it’s under development in Axon 0.7) that picks up that event and sends out a command to update the other aggregate.
In you case, the customer details in the Order probably have to be updated when a customer has been updated. But that makes me wonder: the customer inside an order, is that really identical to the stand-alone customer? Typically, when an order is confirmed, data remains unchanged. If you change a Customer’s address, that won’t automatically change the Order’s address. The problem you’re facing could be a sign that something is wrong in the design of your model.
Cheers,
Allard
Hi Allard,
Thank you for your response.
An aggregate should never directly reference any entity outside of that
aggregate. The only type of reference allowed is by identifier.
So we'd better reference only the Customer ID instead of Customer
entity.
But, this does not apply to Order -> Order Items does it ? Since we
can only add Order Items through Order ?
If an activity in one aggregate should result in a modification of another,
you should ask yourself this question first: aren't these supposed to be
inside the same aggregate? The answer to that question depends on the
consistency requirements that these changes have.If they are really two separate aggregates, you should create an Event
Listener or better, a Saga (but it's under development in Axon 0.7) that
picks up that event and sends out a command to update the other aggregate.
My question, what's the difference between the upcoming Saga and the
mechanism we have so far ?
In you case, the customer details in the Order probably have to be updated
when a customer has been updated. But that makes me wonder: the customer
inside an order, is that really identical to the stand-alone customer?
Typically, when an order is confirmed, data remains unchanged. If you change
a Customer's address, that won't automatically change the Order's address.
The problem you're facing could be a sign that something is wrong in the
design of your model.Cheers,
Allard
Thanks & Regards,
Setya
Op 03-01-11 03:06, Setya wrote:
An aggregate should never directly reference any entity outside of that
aggregate. The only type of reference allowed is by identifier.So we'd better reference only the Customer ID instead of Customer
entity.
Correct, assuming that the customer is not part of the order aggregate.
But, this does not apply to Order -> Order Items does it ? Since we
can only add Order Items through Order ?
The order item is most probably part of the order aggregate. So in that case a direct link is preferred.
(I can not answer your question about saga's.)
Regards,
Erik.
Setya,
the current mechanism involves infrastructure classes that accept events. Of course, you can easily create an Event Listener that emits commands for incoming events. But when the Event Listener needs state to do so, it will quickly become more complex.
In the case of Sagas (thanks to James for pointing that out), each Saga instance is responsible for keeping track of a single “business transaction”. Axon provides the necessary infrastructure classes, which make it a lot easier to create event listeners that require state to process incoming events. Axon will initiate a new Saga when required, and it will be cleaned up when the “transaction” has ended. Saga state is also automatically persisted.
Hope that helps.
Cheers,
Allard