These are chat archives for RBMHTechnology/eventuate

8th
Nov 2017
Volker Stampa
@volkerstampa
Nov 08 2017 11:43
I am not sure I understand your problem entirely, but in general I would say that events used by eventuate to update read and write models of your application are most useful if they represent the actual events that happen in your domain. If the domain is about persons and their demographic data and the managed persons somehow inform the system for example that they relocated it could be very useful to have a corresponding event like PersonRelocated. That means that you would typically not want to have a single (technical) PersonUpdated event that seems to be suitable in the beginning from a technical standpoint as it typically suffices to perform your updates, but you rather want to model the events that actually happen in your domain and keep the intentions. This comes with some advantages. For example in case of concurrent events you have a much better chance to solve a conflict according to your domain's requirements. In case of two technical PersonUpdated events it might be hard to tell which of the fields of the events should define the state of the write model while in case of events like PersonRelocated and PersonMarried it can be easy to tell there is no real conflict. These kind of semantically rich events could also give you the chance to evolve your application much better for example when building additional read models in the future that can be based on the captured intentions instead of plain update information.
Not sure, if this answers your questions, though.
Odd Möller
@odd
Nov 08 2017 12:15
@volkerstampa Such a great answer! :+1:
Volker Stampa
@volkerstampa
Nov 08 2017 16:45
@odd Thanks :-)