Thinking in Events - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

Thinking in Events¶

Most of us never learned Event Sourcing as a way of thinking. We learned it as a collection of parts. An event store goes here. A read model goes there. When things turn asynchronous, you reach for a saga, and when reads and writes start pulling in different directions, you reach for CQRS. We assemble the pieces the way the tutorials drew them, and for a good while the system holds together.

Then a question arrives that no tutorial covered. Should this be one stream or two? Does this failure belong in the log? Who owns this piece of state? The patterns go quiet, because we learned their shapes without the reasons that gave rise to them. Underneath the patterns, though, there is something smaller and steadier, and a while ago we tried to write it down: a short manifesto that everything else turns out to be a consequence of. Here it is, and here is what it means.

Patterns Are Consequences, Not Rules¶

A rule tells you what to do. An axiom tells you why. When all you have is a bag of rules, every new situation becomes a lookup, and the lookup can miss, because nobody wrote a rule for the exact case in front of you. When you have the foundation instead, you do not look anything up. You derive the answer, the same way you would derive it for a case no one has seen yet. The patterns are not the starting point. They are what falls out once the foundation is in place.

This is also why so many teams can recite the patterns and still build something that fights them. They have memorized the conclusions without ever meeting the premises, and conclusions without premises are just folklore. We have circled this before, in It Was Never About the Database and in DDD: Back to Basics : the value was never in the machinery, but in the understanding the machinery is meant to serve.

So a while ago we tried to compress that understanding into something you can hold in your head. Not a tutorial, not a checklist, but a manifesto. Four sentences, each with a few words of explanation, and nothing more.

A Foundation in Four Sentences¶

Event-based software development rests on three notions: Commands (intent), Events (fact), and State (interpretation). It reaches beyond this triad into Integration.

Commands are intentions, the origin of Events. Everything begins with an intention. Someone wants something, and from that intention a fact arises. The Command faces the future, the Event the past. Yet the step from intention to fact is not automatic. Between them stands a decision. A Command may be refused. An Event, once it happened, cannot.

Events are the natural language of stories, immutable and ordered. They tell what happened, in the language of the domain. Once written, they never change, and they stand in an order that makes cause and effect visible. Whoever has the Events of a story has the story. And when something was wrong, we do not erase the past. We add to it. A correction is a new Event, never a changed one.

State is an interpretation of Events, one of many. State is not the truth. The truth lies in the Events. What we call State is a view, derived from Events, for a particular purpose. For every question asked of the story there is its own interpretation. Many are possible, side by side. And because State is derived, it can be discarded and rebuilt at any time.

Integration rests on Events, not on shared State. Systems and contexts do not meet through shared databases, but through what they tell each other. An Event that crosses a boundary is a message from one story, which the other translates into its own. And an Event crossing a boundary may become the origin of a new intention on the other side.

These four sentences are not a textbook, but a foundation. From them the familiar tools follow as consequences, not as rules: Ubiquitous Language and Bounded Contexts, Event Stores, CQRS and projections, Sagas and Context Mappings. And when a decision grows difficult, or when someone asks why, the path leads back to these four.

That is the whole of it. What follows is not more manifesto, but a walk through the weight each sentence carries, because a foundation you cannot feel is just a slogan.

Commands, and the Decision That Can Say No¶

Start with the first sentence. Its explanation hangs on one small word, the one that does the most damage when it is missed: refused. Because a Command can be turned down and an Event cannot be unsaid, the two are not one thing in two tenses, however much BorrowBook and BookBorrowed look like a matched pair. They differ in whether they can fail, and that single difference...