Skip to content

Perspectives

Don't Kill Your Users

When I consult customers on Event Sourcing, there's a moment that happens almost every time. The team looks confident, maybe even a little proud. They tell me: "Actually, we already do Event Sourcing." And then they show me their events. UserCreated. OrderUpdated. InvoiceDeleted. My heart sinks a little.

This is not Event Sourcing. This is CRUD with event syntax. It has the shape of events but none of the semantics. And that distinction, subtle as it may seem, is the difference between a system that speaks the language of your business and one that speaks the language of databases.

One Database to Rule Them All

"Should we use one EventSourcingDB for all our services, or should each service have its own?" This question comes up in almost every conversation about service-based architectures. Teams want to keep things simple. One database sounds easier to manage than five. The appeal is understandable.

But here's the thing: this isn't a question specific to EventSourcingDB. It's one of the most debated topics in software architecture, regardless of database technology. Whether you're using PostgreSQL, MongoDB, or an event store, the fundamental question remains the same: should multiple services share a database, or should each service have its own?

If you've read Tolkien, you know that "One Ring to Rule Them All" didn't end well. The same is true for shared databases. What looks like elegant simplicity becomes a source of coupling, conflict, and constraint. Let's explore why.

... And Then the Wolf DELETED Grandma

Last week, I had the pleasure of speaking at the Software Architecture Gathering 2025 in Berlin. The conference is organized by the iSAQB (International Software Architecture Qualification Board) and brought together around 400 attendees from numerous countries. My talk, titled "... And Then the Wolf DELETED Grandma," explored why CRUD falls short when modeling real-world processes, and about 120 people joined me in the room to discuss fairy tales, databases, and the limits of our industry's favorite paradigm.

The response was overwhelming. Conversations continued long after the session ended, and many attendees shared similar frustrations with CRUD in their own projects. This post is the written version of that talk: for everyone who couldn't be there, and for those who were and wanted to revisit the ideas.

Event Sourcing is Not For Everyone

A few days ago, Martin Dilger published an article on LinkedIn titled "When Event Sourcing Doesn't Make Sense (And How to Know the Difference)". It's a thoughtful piece that addresses an important question: when should you not use Event Sourcing? The article sparked several private conversations, and one in particular revealed a confusion I see far too often.

Someone described a ride-sharing application where a driver continuously transmits GPS coordinates while traveling to pick up a passenger. The question was: are these GPS updates events? And if so, should they be stored using Event Sourcing? The answer reveals a fundamental distinction that many teams overlook: not everything that looks like data is an event, and not every event belongs in an event-sourced system.

If You Apply DDD to DDD, You Won't Get DDD

Domain-Driven Design (DDD) promises better software through a focus on the business domain and a shared understanding between developers and domain experts. That's the essence, distilled to one sentence. But if you actually apply this principle to DDD itself – asking what the domain is, what matters, what can be discarded – you won't end up with what we call "DDD" today. You'll end up with something much simpler.

So why has DDD, after more than two decades, never escaped its niche? Why do so many developers feel overwhelmed by it, confused by it, or think they're not smart enough for it? The answer is uncomfortable but clear: DDD fails at its own claim.