Skip to content

What's New

REST in Peace

REST has become the de-facto standard for building web APIs. Almost every tutorial, framework, and job listing treats it as the obvious choice. But what most developers call "REST" has very little to do with what Roy Fielding described in his dissertation back in 2000. Today, REST typically means HTTP verbs, JSON payloads, and CRUD operations mapped to resources. And that is exactly where the problem begins.

Because once you strip away the buzzword, what remains is a thin wrapper around database operations, exposed over HTTP. We have spent years criticizing CRUD on the data level. It is time to look at what CRUD does to our APIs.

Hidden in Plain Sight: The Events You Forgot to Model

There's a very specific moment that most teams working with Event Sourcing eventually run into. Someone asks a seemingly simple question about the past: why did this happen, how often has that occurred, what would have been the case if things had gone differently. You open the event store, expecting the answer to be right there, because that's the promise, after all. The full history, nothing lost, everything reconstructible. And then you realize the event you'd need was never written. The information existed once, for a brief moment, and slipped away before anyone thought to catch it.

It's tempting to treat this as a checklist problem. Just write down the events you tend to forget, keep the list handy, refer to it during the next Event Storming. But that approach misses something important. The problem isn't that teams are lazy or careless. It's that the way we're taught to think about events quietly steers us away from certain kinds of events in the first place. If you want to stop forgetting them, it helps to understand why they vanish from the model to begin with.

A Skill for Easter: Teaching Claude to Speak EventSourcingDB

Two weeks ago, we introduced the MCP Server 1.0 for EventSourcingDB, connecting AI agents to your event store through the Model Context Protocol. It showed what becomes possible when LLMs can query events, inspect subjects, and run EventQL in natural language. But setting up a Docker container and configuring an MCP client is not always what you want when you just need to quickly interact with your database. Sometimes you want something lighter.

As a small Easter gift, we are releasing a Claude Code Plugin for EventSourcingDB. It is a set of Skills that teach Claude how to use the entire EventSourcingDB API. No SDK installation, no Docker container, no MCP configuration. You install the plugin, and start talking to your event store. Think of it as the lightest possible bridge between natural language and your events.

Introducing Simple Mode

Over the past few months, we have received more feedback than ever before. Hundreds of conversations with developers, architects, and CTOs have painted a remarkably consistent picture. The message was clear, and we owe it to you to be honest about what we heard: Event Sourcing is too complex. Not in theory. In theory, everyone loves it. But in practice, teams struggle. They struggle with modeling, with naming, with the sheer cognitive overhead of thinking in events rather than rows.

Debugging Event-Sourced Systems: A Detective's Guide

In a traditional CRUD system, debugging starts with a familiar question: "What is the current state?" You open the database, look at the row, and see that the order status is "cancelled." But you do not know why. Was it the customer? The payment provider? An automated process? The database shows you the crime scene, but not the crime. All you have is a body and no witnesses.

Event-sourced systems turn this on its head. Instead of inspecting the current state and guessing what went wrong, you follow the trail of events. Every change that ever happened is recorded, timestamped, and preserved. Debugging becomes less about guessing and more about reading. You are not a detective arriving at a cold case. You have a complete surveillance tape.

Introducing DDD to Your Organization

You have read the books. You have watched the talks. You are convinced that Domain-Driven Design would help your team build better software. The models would be clearer, the communication with stakeholders sharper, the architecture more aligned with the business. There is just one problem: nobody else in your organization knows what DDD is, and nobody asked for it.

Introducing DDD is not a technical challenge. It is a cultural one. You cannot install it like a library or deploy it like a service. It requires changing how people think about software, how they talk about problems, and how they collaborate across disciplines. That takes time, patience, and a strategy that goes beyond "let me show you this cool pattern."

Naming Events Beyond CRUD

You open the event store and see UserUpdated. What happened? Did the user change their email? Did they accept the terms of service? Did an admin reset their password? The event name tells you nothing. It is CRUD in disguise, a technical label that hides what actually occurred.

Now consider OrderDeleted. Why was it deleted? Did the customer cancel? Did the seller reject it? Was it flagged for fraud? Behind the same technical verb lie completely different business realities, each with its own consequences, its own rules, its own downstream effects. The name you give an event determines whether your system tells a story or keeps a secret.

Decide, Evolve, Repeat

Almost every Event Sourcing implementation starts with aggregates. You define a class, give it a method for each command, mutate internal state when events are applied, and wire it all up with a framework. This works. Countless systems have been built this way. But if you step back and ask what Event Sourcing actually needs at its core, the answer is surprisingly minimal.

The Decider pattern, introduced by Jérémie Chassaing, strips Event Sourcing down to three functions. No classes. No inheritance. No framework. Just three pure functions that capture everything an event-sourced component does. It is one of the most elegant ideas in the Event Sourcing space, and once you see it, it changes how you think about the entire approach.

Introducing the MCP Server 1.0 for EventSourcingDB

AI-powered agents are no longer a future promise. They are here, embedded in development workflows, automating decisions, analyzing data, and helping teams move faster. Tools like Claude, ChatGPT, and Gemini have become part of the daily toolkit for developers and architects alike. But until now, these agents had no way to talk to your event store. They could reason about code, summarize documents, and generate queries, but they could not read your events, explore your subjects, or run an EventQL query against live data. The most valuable data source in an event-sourced system was invisible to AI.

Today, we are changing that. We are releasing the MCP Server 1.0 for EventSourcingDB, an extension that connects large language models directly to a running EventSourcingDB instance. It implements the Model Context Protocol, an open standard that defines how AI models discover and invoke external tools. With this release, your AI agents can read events, write events, browse subjects, inspect event types, register schemas, and run EventQL queries, all through natural language.

All Models Are Wrong, Some Are Useful

"All models are wrong, but some are useful." The statistician George Box wrote this in 1976, and it remains one of the most underappreciated truths in software engineering. We spend weeks, sometimes months, trying to build the perfect domain model before writing a single line of code. We draw diagrams, debate naming, argue about boundaries. The intention is good: get it right upfront so you don't have to fix it later.

But the pursuit of the perfect model is itself a trap. Models are always incomplete, always a simplification of a reality that is too complex to capture fully. The question was never whether your model is right. It was always whether your model is useful enough to start, and whether you know how to evolve it when reality teaches you what you missed.