So…I’m back in front of a text editor (and not behind a camera) and this cropped up just as I logged into the forum again after — checks calendar — a solid 18 months away! I’ve switched careers but still plan to do some software here and there, mainly building out ideas for myself and those close to me.
One idea would suit ES, but some time away has provided a bit of clarity. Why use event sourcing when it’s a pattern that requires a lot of ceremony and almost always come with CQRS which can be a burden, even just from deployment costs for a zero-income idea.
I’m now wondering if I could simply design my database architecture in a way that captures changing data, rather than just throwing away the old. Querying current data would require a more complex join (perhaps finding the latest version of some fields, rather than having the current data denormalised on the read side of CQRS).
In short, how much value do you feel event sourcing offers, versus simply designing your database in such a way that data isn’t thrown away?
Event sourcing is not just about persisting all application state changes. Event sourcing is about linearization of events and reproducibility of state changes, which is useful only in some parts of the system (like something related to money or extremely secret data). This approach must not be used for all entities and events in the system.
To persist all entities (even changed or deleted ones), you can simply use deleted boolean column (which is common, but not recommended) or have the clone for each table just in another schema.
An other place where event sourcing shines is when there is a temporal aspect in your problem space. If you only have crud operations ES will not offer a lot of value.
On the other hand. If you need to model complicated processes ES can deliver!
It’s true that ES might require different architectural design (different but more). That’s definitely something too consider but if you model only some entities with ES you might not need that.
