Skip to content

What's New

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.

Welcoming Nimbus: Event-Driven Development for TypeScript

Today we're thrilled to celebrate the launch of Nimbus, a new event-driven application framework for TypeScript built by our friends at Overlap in Vienna, Austria. Nimbus integrates natively with EventSourcingDB and brings clear, explicit support for commands, events, and queries to the JavaScript and TypeScript world. We're genuinely grateful to be celebrating this with them. Overlap has built something thoughtful and substantial, and the JavaScript and TypeScript world is better for it.

We won't pretend Nimbus is the first attempt to bring CQRS and Event Sourcing into JavaScript. There have been several over the years, including our own historical effort, wolkenkit. What makes Nimbus stand out is not novelty, but approach: a deliberately minimalist, explicit design built from day one around a dedicated event store. It's also a sign of something larger, a quiet but unmistakable shift in how serious teams are choosing to build software.

Email Uniqueness in Event Sourcing

Recently, a reader asked us how to enforce email uniqueness when registering users in an event-sourced system. It is a fair question. In a relational database, you add a column, slap on UNIQUE, and the problem is solved. The database does the heavy lifting, and you move on with your day. In Event Sourcing, that easy answer simply does not exist.

The good news is there are several reasonable ways to solve it. The bad news is that none of them is free. Each one pays for uniqueness somewhere, whether in scale, in latency, in user experience, or in operational complexity. Choosing among them is not a technical question. It is a question about what your business actually means by "unique."

Great Minds Should Not Think Alike, They Should Think Together

The Event Sourcing, Domain-Driven Design, and CQRS community is full of brilliant people. Thoughtful practitioners, passionate speakers, prolific authors. People who genuinely care about building better software through deeper domain understanding. And yet, for a community built around the idea of shared understanding, we have a remarkably hard time understanding each other.

The irony is hard to miss. We preach Ubiquitous Language as a cornerstone of Domain-Driven Design, insisting that teams must develop a precise, shared vocabulary for their domain. But when it comes to our own discipline, we can't even agree on what to call the things we work with every day. And that's just the beginning.

It's None of Your Business

Three weeks ago, we introduced Simple Mode, a new mode for EventSourcingDB that replaced expressive domain events with three universal operations: row-inserted, row-updated, and row-deleted. Many of you laughed. Some of you forwarded it to colleagues who were not sure whether to laugh or cry. But beneath the satire, the frustrations we exaggerated were real. Teams genuinely struggle with Event Sourcing, and the reason they give is almost always the same: "It's too complex. We just want to store data."

We have heard that sentence dozens of times. And every time, we have come to the same conclusion: the complexity is not the problem. The problem is a misunderstanding about whose job it is to make business decisions. Because right now, in codebases all over the world, developers are making those decisions every single day, quietly, implicitly, and almost always without realizing it. And that is where things go wrong.

Sagas vs Process Managers

The moment a workflow spans more than one aggregate or service, someone will say: "We need a saga." It has become the default term for anything that coordinates multiple steps in an event-driven system. Book a flight, reserve a hotel, charge the credit card, and if any step fails, roll everything back. That's a saga, right?

Not quite. What most people describe when they say "saga" is actually a different pattern with a different name, different responsibilities, and different trade-offs. The confusion is not just semantic. It leads to architectural decisions based on the wrong mental model, and those decisions are surprisingly hard to reverse.

Blueprinting the System: An Interview on Event Modeling

Golo: Adam, you created Event Modeling and have been teaching and refining it for years now. You are also the founder of AdapTech Group and have worked with countless teams on adopting this approach. Before we dive into the method itself, can you tell a little about what problem you were originally trying to solve? Was there a specific frustration with existing approaches that led you to develop something new?

Elixir Client SDK 1.0 Now Available

Today we're excited to announce the release of the official Elixir Client SDK for EventSourcingDB, version 1.0. If you're building event-sourced systems on the BEAM, you now have first-class support for writing, reading, and observing events from your Elixir applications.

Elixir has earned its place as one of the most compelling platforms for building fault-tolerant, distributed systems. With this SDK, we're bringing EventSourcingDB into that world, and we've made sure it feels like Elixir from the ground up.