Skip to content

Event Sourcing

The Write Model: Where Business Logic Lives

Every software system makes decisions. When a customer submits a loan application, something in your code decides whether that application is valid. When an employee approves a claim, something verifies that the approval is allowed. These decisions are the most important thing your software does - they are the reason the system exists.

When you think about software from the domain's perspective - what the business actually does, what decisions it makes, what rules it enforces - a natural question emerges: where in the code does all of this live? Domain-Driven Design encourages thinking in terms of business processes and decisions rather than data structures and technical layers. CQRS and event sourcing take this further by giving the decision-making part of your system an explicit, well-defined home: the write model.

The write model is the single, self-contained unit that takes the current state of your system, applies your business rules, and produces a decision - nothing gets written without passing through it first. In the previous article in this series, I explored read models - purpose-built data structures that transform your event stream into exactly the shape each consumer needs. This article looks at the other side of the equation: where read models answer "what should the user see?", the write model answers "is this operation allowed, and what happens as a result?"

One Truth, Many Views: Understanding Read Models in Event Sourcing

If you have spent any time building web applications, you are familiar with a pattern so ubiquitous that it feels like a law of nature. You have a database, you write data to it, and you read data from it - same tables, same schema, same source. Your SELECT queries run against the same rows your INSERT statements created. The mental model is simple: one database serves all purposes, and every part of your application sees the same data in the same shape.

Event sourcing breaks this assumption. In an event-sourced system, your write side does not store rows in a table - it stores a sequence of events in an event store. When a customer submits a loan application, you do not write an applications row with columns for name, amount, and status - instead, you store a LoanApplicationSubmittedEvent that captures the fact that something happened. Your write site replays these events to reconstruct the current state of the application, makes its decision, and publishes more events. The data is there, but it lives in a stream of facts, not in a queryable table.

This raises an immediate and practical question. Where does the data for your user interface come from? A bank employee needs a dashboard showing all pending applications with their risk categories. A customer needs a status page confirming that their application is under review.