Real-World Event Sourcing

Justifying Model Separation

In a traditional application, you might store data in tables and then link all that data together with keys. When your application wants to display a list of users, it can query the user table and join it with the address table, then join that with a ZIP code table, and so on. There’s nothing inherently wrong with this, but you’re out of luck if you need to know how or when a person’s address became their current one. Without an event log, that information doesn’t exist.

You need both the event log (write model) and the user, address, ZIP code, billing, preferences, and other data (read model). But using the same data structure for both is at best impractical, and at worst impossible. If you had to query the entire ...