0

How to handle a next kind of situation in general:

I've defined two aggregate root types AR1 and AR2. The AR2 holds value-based identity of the AR1. I have to keep eventual consistency between those aggregates so if some command changes the state of the AR1, I have to change states of every AR2-objects, which hold the specific identity of the AR1 instance. Without event sourcing I can query those AR2 objects from repository using findByAR1Id()-method but how can I achieve the same result using event sourcing?

1

Without event sourcing I can query those AR2 objects from repository using findByAR1Id()-method but how can I achieve the same result using event sourcing?

You can do the same thing, it's just uglier to implement.

What does that query really say in the "without event sourcing" case? Find all AR2 objects where the current state of some field is the AR1.Id. So your basic implementation of findByAR1Id looks just like that -- parse your event history to compute the current state of each AR2, check if the fields match, etc.

Ugly.

With some event stores, you can try to cheat -- get all of the events that set the AR2 property to the AR1 id that you are looking for, then reload only the AR2 objects referenced by those events, and check their current states as before.

can be a big help here -- if this sort of thing happens often, then use the stored events as the source of a read model that keeps track of which AR2's reference each AR1. In other words, use the events to build a replica of the data store you would have queried originally, and (asynchronously) update the data store when new events are published. When you need an answer to this query, you run it against the current view of that database.

The event store is still the book of record, which is to say the source of "truth"; the read model is just a picture of what it looked like at some point in the past -- there's going to be a bit of latency between when you save an event, and when the query shows the change. If your aggregates are well designed, that's usually OK -- all of your aggregates will be internally consistent, they just disagree with each other from time to time.

  • I think the query-over-eventstore search-style "repository" can actually isolate the "ugliness" and this solution would work for a while. Read models add complexity and it might not be something to consider when in spike phase, something to do when stabilising. adaptechsolutions.net/evolving-architecture-by-cheating – Alexey Zimarev Jan 23 '17 at 11:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.