Skip to content

2026

You Don't Need an Outbox

The outbox pattern has quietly become canonical in microservice tutorials. It has a name, library support, conference talks, and a steady stream of blog posts that walk through implementing it. It's blessed. And yet, every time it shows up in a system, it's a sign that something else has gone wrong upstream.

The pattern itself is clever. It works around a real, structural problem: two systems that need to agree but can't share a transaction. The question worth asking is whether you need to have that problem in the first place. Once you take that seriously, the outbox stops looking like a pattern and starts looking like an admission of defeat.

Commands Aren't Just Events in Reverse

BorrowBook and BookBorrowed. ReserveSeat and SeatReserved. AcquireBook and BookAcquired. The first half is what someone wants, the second half is what happened, and the only visible difference is the tense. Most diagrams in most Event Sourcing tutorials draw the two as a pair, and after enough examples, your brain quietly starts assuming they always will be.

That picture gets people started, and it isn't wrong, exactly. But the more real your system becomes, the less it matches the shape of what's happening underneath. Commands and events look symmetric on the surface, and they're not. They're not symmetric in whether they can fail. They're not symmetric in who they speak to. They're not even symmetric in number. Treating them as if they were is one of the quietest, most expensive mistakes we see, because the code keeps working long enough for the asymmetry to set in everywhere before anyone notices.

What's an Entity, Anyway?

I've worked with Domain-Driven Design for fifteen years, and I'll admit something I usually keep to myself. There's one concept in DDD whose point I've never quite gotten. Not because I haven't read Evans, and not because I haven't built systems around it. I've done both. But every time I sit with the concept of the Entity and ask myself what it's actually for, I come away with the same shrug. Value Objects feel intuitive. Aggregates feel intuitive. The Entity feels like a placeholder that everyone agreed to keep teaching anyway.

A conversation a few days ago finally produced the click I'd been waiting for, and the answer surprised me. The confusion wasn't a personal blind spot. The concept itself has been quietly hollowed out by the very ideas that surround it, and most of us keep teaching it as if that hadn't happened. The Entity isn't broken. It's overshadowed. And the shadow only lifts once you start asking what would happen if the thing casting it weren't there.

Is DDD Overkill for My CRUD Project?

We hear it almost every week. A developer leans back, half-smiles, and says something like: "Domain-Driven Design? Sure, for a big enterprise system. But mine is just a simple CRUD app. Wouldn't DDD be total overkill?" The tone is friendly, sometimes even a little apologetic, as if they're letting us down gently. And the reasoning sounds airtight. CRUD is simple. Domain-Driven Design is heavy. Why bring a freight train to move a couch?

We get the instinct. Most of us have rolled our eyes at a slide deck full of Bounded Contexts for an app that, frankly, has one table and three buttons. But once you scratch the surface of this question, two different things turn out to be hiding under the same word. One of them really is overkill for your CRUD app. The other one isn't even optional, and you're either doing it well or doing it badly right now, whether you call it DDD or not.

Your Read Model Doesn't Always Need a Database

Sooner or later, every team building an event-sourced system runs into the same question: which database should we use for the read model? The textbook answer is reassuringly pragmatic. It depends. Pick the tool that fits the access pattern. Relational if you need joins and ad-hoc queries, document-oriented if your data is hierarchical, key-value if you mostly look things up by ID, a graph database for relationships, a spatial database for geodata, and so on.

That advice is sound, and yet it quietly assumes something that nobody ever questions: that there has to be a database in the first place. There's one option that almost never makes it onto that list, and it's the one that turns the whole question on its head. For a large class of read models, you don't need a database at all. You can keep the entire read model in memory and serve it straight from there.

Continuous Modeling, or What Happens to the Model on Tuesday?

Friday afternoon. The sticky notes on the wall are the densest they've been all week. Someone has redrawn a Bounded Context for the third time, and this time everyone in the room nods. Two product managers, three engineers, a domain expert, and a coach who's been keeping the conversation honest agree: this is what the system actually is. Phones come out, photos get taken. People shake hands and say things like finally, and now we know. The room empties.

On Tuesday, someone opens a pull request that touches the boundary you spent half of Friday redrawing. The PR description doesn't mention the model. The reviewer doesn't mention the model. The model is in three Miro boards, one of which is now read-only because somebody's account got rotated, and a Confluence page that hasn't been opened in four weeks. The reviewer approves the change. The model isn't wrong yet. It's just not anywhere the work can see it. Three months later, when a new question forces you back to the wall, no one quite remembers why the boundary was where it was. Did the workshop fail? It didn't. Something else did, and almost every team we talk to keeps making the same quiet mistake.

How Can I Force Myself to Stop Thinking in Technical Solutions?

Henry Ford is often quoted as having said, "If I had asked people what they wanted, they would have said faster horses." The line is probably apocryphal, but the picture it paints is accurate. People describe solutions, not problems. They say "I need a queue" when what they mean is "things keep getting lost between two systems." They say "we need a microservice" when what they mean is "this part of the codebase is painful to deploy." The technical answer arrives before the question is even formed, and that is true for product owners, business stakeholders, and developers alike.

This is the trap every thoughtful developer eventually wants to escape. After a few years, you start to notice that the systems you build are answering the wrong questions. You read about Domain-Driven Design, you learn the words "ubiquitous language" and "bounded context", and you decide that from now on, you'll think about the business first and the technology second. Then you walk into your next meeting, and within ninety seconds you're already drawing tables on the whiteboard. You wanted to stop. You couldn't. This post is about why, and about the only thing we've actually seen work.

Ubiquitous, But in Which Language?

A few years ago, we sat in a workshop room in Switzerland with a team that wanted to build an event-based dispatching system for their industrial operations. The stakeholders had flown in from across the country, from the German-speaking north, the French-speaking west, and the Italian-speaking south. We had everything Domain-Driven Design tells you to want, the right people in the room, real domain expertise, real business problems to solve. What we didn't have was a shared mother tongue.

Domain-Driven Design rests on the idea of a Ubiquitous Language, a precise vocabulary that every member of a project uses identically, in every conversation, every document, and every line of code. It's beautiful in theory. But it quietly assumes there is one language to be precise in. In a surprising number of real projects, there isn't. What we did in that Swiss workshop, what another client of ours did in an even more radical way, and why this matters more in Event-Sourced systems than almost anywhere else, is what this post is about.

Two Maps, One Domain

Most teams who say they "do Domain-Driven Design" are doing tactical DDD. Aggregates, Entities, Value Objects, Repositories. They write code that follows the patterns, draw diagrams that show the building blocks, and argue about whether something belongs in the domain layer or the application layer. It feels like DDD. It looks like DDD. And it is, in a narrow sense. But it's only one half of the picture. The other half, the strategic half, is where most teams quietly drift, often without noticing.

Strategic Design is the part that gets learned last. It's also the part that quietly determines whether your architecture aligns with the business or fights it. Inside Strategic Design lives a distinction that, once you see it, you can't unsee: the difference between the problem space and the solution space, and how Subdomains and Bounded Contexts inhabit them. Most teams either don't make this distinction at all, or they collapse it into a 1:1 mapping that feels tidy and turns out to be wrong. Let's pull it apart.

One Year of EventSourcingDB, and the Language That Belongs Beside It

A year ago today, on the 5th of May, 2025, we shipped EventSourcingDB 1.0. We've spent the months since watching teams take it into production, hearing the stories of what they built on top of it, and learning more about the rough edges of event-driven work than we did in the decade before. Today, exactly twelve months later, we're not here to celebrate the past. We're here to take the next step.

Because somewhere along that year, a quiet thought turned into a loud one: a great place to store your events isn't enough. The events themselves carry meaning that lives outside the database, in the model you and your team carry around in your heads, on whiteboards, in slide decks. That model deserves a home of its own. Today, we're giving it one. Meet ESDM, the Event-Sourced Domain Modeling language.