The printout lies on the table between us with one line marked in red. 31,400 euros, approved by N. Prentice, March 27, 14:52.
The N stands for Naomi. It is my line, and every number on it is correct.
Merrick asks whether I was authorized to do that. I say yes. He asks whether I can prove it.
Golo: Martin, you're the founder of Nebulit and the author of Understanding Eventsourcing, a book that deliberately refuses to treat Event Modeling, Event Sourcing, and Vertical Slice Architecture as three separate topics, and instead weaves them into a single, coherent way of building software. You also co-host the Event Modeling and Event Sourcing podcast, so you spend a lot of your time thinking out loud about this space. Over the last year, though, your attention has visibly shifted toward something new: getting AI agents to turn an event model into running, production-grade code, with as little human support as possible. Before we open the hood, take us back to the moment this clicked for you. What made you point your attention at autonomous code generation, and what convinced you it was more than the usual AI hype?
Sooner or later, every serious system meets an auditor. Compliance, regulation, or plain good governance shows up and asks for the same thing: a complete, ordered, tamper-proof record of what happened and when. And almost every architecture review answers with the same reflex. Add an audit log. It has the right name, it produces something you can point at, and it feels responsible. In most systems, it is also the wrong answer.
This is not a case against auditing. Auditing matters, often more than the features built around it. It is a case against the separate audit log as the way to deliver it, because a good auditor, one who actually does the job, will take about one meeting to see through it. The reason they can is the same reason the audit log was compromised from the start, and it reaches all the way down to how you decided to store your data in the first place.
Today, we're introducing a new pricing model for EventSourcingDB. Until now, it came with a single commercial license and little else: one price, the same for everyone, whether you were a solo developer with a side project or a company running it in production. That was simple, but simple and fair are not always the same thing.
So we've opened the model up. It still fits on a single page and still shows every number in public, but it now makes room for the whole range of people who build on EventSourcingDB: a genuinely free tier, a reduced rate for individual developers, quarterly terms alongside yearly ones, and special conditions for startups, non-profits, and larger scale. Here is what it looks like, why we shaped it this way, and a quick way to tell which license is yours.
Every time a team sits down to build an event-sourced system, someone asks the same question: we already run Kafka, and Kafka is an append-only, ordered log, so isn't that exactly what Event Sourcing needs? The resemblance is real, and it is tempting. It is also superficial, and mistaking one for the other tends to get expensive months later, once the system is in production and the workarounds have quietly piled up.
So rather than arguing that Kafka is bad, because it is not, we want to do something more useful. We will first pin down what an event store actually has to do, then hold Kafka against that list and see where it stands. This is the first post in a small series that asks the same question of one candidate at a time. And for Kafka, the answer is the one that surprises people the least once they can see it laid out: it is an excellent tool, just not for this particular job.
There's a moment that shows up in Event Sourcing projects again and again. The design is going well, the team is sold on the idea, and then a single hard requirement surfaces: GDPR's right to erasure. All at once, storing events immutably looks less like a feature and more like a liability. So the team grants itself one small exception – when someone asks to be deleted, they'll reach into the stored event and overwrite the offending field, turning an email address into "redacted". One small edit, applied rarely, to a system that is otherwise append-only.
It sounds harmless. It even sounds responsible. But that one exception quietly cancels a large part of the reason they chose Event Sourcing in the first place, and they likely won't notice until the day they need one of the guarantees that no longer holds. Because the benefits of Event Sourcing aren't a menu you order from. They all hang on a single thread, and that field overwrite cuts it.
As of today, ESDM is available under the MIT license. The full source of the esdm toolchain, the schema that defines the language, and the documentation now live in a public repository on GitHub. You can read it, use it in any project, and build on it – at no cost and with no strings attached.
We introduced ESDM about two months ago, and we deliberately kept the source in our own hands at first, long enough to sharpen the language through a few rounds of real use before handing it to the world. That stretch is behind us. The core has settled, and today is the day we open it up.
When we released the Claude Code Plugin for EventSourcingDB at Easter, we proudly listed everything it did not need: no SDK, no MCP configuration, not even a Docker container. Claude had learned to speak EventSourcingDB fluently. But there was a quiet assumption baked into every conversation – that somewhere, someone had already started a database for Claude to talk to.
Version 1.1.0 of the plugin removes that assumption. Claude can now start a local EventSourcingDB on its own, and it has picked up a few habits that make longer sessions noticeably smoother: consistent event sources, uniform event type prefixes, and a deeper understanding of the CloudEvents format. In this post, we walk through what is new – along a session that begins with an empty terminal and ends with a queryable event store.
In most software, testing is something you bolt on after the fact: you write the code, then you write tests to convince yourself the code does what you hoped. Event Sourcing quietly inverts that relationship. Because behavior is expressed as events, a test can read like a sentence about the domain: given these past events, when this command arrives, then these new events should follow. The test stops being scaffolding around the code and becomes the specification of what the system is supposed to do.
On June 26th, our friends at Digital Frontiers shipped OpenCQRS 2.0, and the change we keep coming back to leans all the way into that idea. The release modernizes plenty under the hood, but the part that matters most day to day is the redesigned testing support – a fluent DSL that makes those given/when/then specifications read less like test code and more like a conversation with the domain. Let's start with why that conversation is worth having at all.
Golo: Henning, Stefan, you are both working at WPS – Workplace Solutions and you are the creators of Domain Storytelling, a collaborative modeling technique that has gained a lot of attention in the Domain-Driven Design community. Before we dive into the method itself, can you tell us a bit about your backgrounds and how Domain Storytelling came to life?