Re:Event Sourcing (2005)
by bob1029 on Thursday August 12, 2021 @09:27AM
(#28156018)
> If your events are well defined
This is clearly the key to the whole picture.
Reading through this and other comments this morning, and I am starting to develop some concrete notions.
Seems like I simply need to build events for each unique type of fact that could exist in the domain. The verbosity of this seems extreme, but also makes a ton of sense.
The thought in my mind right now - If you combine event sourcing with a model in 6NF, the mapping should be trivial. Every fact table has its own series of events pertaining to it (Create/Update/Delete).
This also seems elegant - If your core data representation is inherently linear, do you care that you have this degree of normalization going on? You have to reconstruct some reasonable in-memory representation from the log anyways, so your live in-memory instance could be ~3NF while it ultimately transacts with a 6NF event log on disk. This also plays nicely with backwards compatibility and data migrations.
This is clearly the key to the whole picture.
Reading through this and other comments this morning, and I am starting to develop some concrete notions.
Seems like I simply need to build events for each unique type of fact that could exist in the domain. The verbosity of this seems extreme, but also makes a ton of sense.
The thought in my mind right now - If you combine event sourcing with a model in 6NF, the mapping should be trivial. Every fact table has its own series of events pertaining to it (Create/Update/Delete).
This also seems elegant - If your core data representation is inherently linear, do you care that you have this degree of normalization going on? You have to reconstruct some reasonable in-memory representation from the log anyways, so your live in-memory instance could be ~3NF while it ultimately transacts with a 6NF event log on disk. This also plays nicely with backwards compatibility and data migrations.