Thread by @daveremy

Most people who learn about Event Sourcing learn it as an application design pattern, which of course it is. However, IMO, the big WHY for Event Sourcing is the Event data model that this pattern enables
1/

To date myself I was fairly early in the relational database space working for IBM in the mid 80s when relational started to take off. A big driver of relational db adoption was that Relational (vs Hierarchical) did not you require you to lock in your query access pattern
2/

When (not if) business requirements change Relational offered assurance you could query data in ways not anticipated in the original design. CTOs, Architects, Devs, even CEOs got the message, most knew that businesses live or die based on their ability to cope with change
3/

The Event data model, underlying Event Stores and Event Sourcing, reminds me of the same type of change in thinking that relational engendered. The Event data model goes one step further, to a more fundamental core data model component, an Event
4/

The Event data model keeps state changes as the fundamental data model and allows you to then “project” into whatever other data model you need to leverage that data on the query side.
5/

This could be relational, document, graph, you name it - when business requirements change you change or regenerate your query model to fit your needs
6/

The Relational data model, with all its power is lossy. The data that it captured was provably queryable however it’s focus is on keeping current state of the data. Deletes (obviously) and Updates (less obviously) are lost .. it is not possible to query data once it is gone
7/

The Relational data model “collapses” the underlying state changes into a specific current state data model that is flexible but not particularly optimized for either querying or writing
8/

A Relational “normalized” data model will break logical business entities into multiple tables which must both be written too and read from to get the data … as so many of us know when needing to do 10 table joins for common queries
9/

Event Stores and the event data model represent a separation of concerns with Event Store focused on optimizing append only streams of events and feeding those events in “real time”, to whatever query engine most appropriate for your use case
10/

Event Store databases and the Event data model may seem new and revolutionaryish, in some ways they are, however they are also evolutionary. Most db technologies as well as distributed consensus algorithms have a “log” as their fundamental underlying data structure
11/

Event Stores are unbundling this log and proposing it as the database itself
12/

A sign of the growing maturity of the Event data model is the Event data design methodologies that have emerged from analysis down to implementation (event storming, event modeling, etc.)
13/

One aspect of the Event data model is that underlying events implemented at the db level tend to be isomorphic with the design artifacts. In other words the events in the db tend to represent business understandable events and language
14/

This can have profound implications, your systems monitoring will also be business monitoring for one …
15/

Event Store’s have the potential to be the next generation of operational, “source of truth”, transactional database technology
16/

Their nature of being non-lossy with a first class streaming API put them at the confluence of multiple macro trends such as (micro)services, the explosion of powerful analytics and integration technologies, blockchain, and AI
17/

Event Sourcing as an application development pattern is a powerful tool for building modern systems, especially distributed asynchronous ones. This is an important consideration and may be enough for you to decide to choose the Event Sourcing pattern ...
18/

However there is another powerful consideration, arguably the most important, which is the value of underlying data and the Event data model itself ...
19/