Skip to content

Perspectives

Three Conversations Worth Having With Your CTO

You have built something good. The architecture is solid, the code is clean, the team knows what they are doing. But when you suggest a foundational change, like rethinking how data is stored, the conversation stalls. "What is the business case?" "What problem does this solve?" Fair questions. Hard to answer in a hallway conversation.

This post is for that conversation. Not the technical one (you already understand that), but the business one. Three problems that cost real money, that your CTO cares about even if they do not know the technical details, and that have solutions your team can implement.

Soft Delete Is a Workaround

Three weeks ago, Alex Buchanan published a thoughtful blog post about soft delete strategies. In "The challenges of soft delete", he describes the problem carefully and offers four creative solutions. His analysis is thorough, his examples concrete, and his engineering instincts sound.

His analysis is correct, his solutions well considered. But all four strategies have something in common: they optimize a problem that does not exist with a different architectural approach.

What Aviation Teaches Us About Auditing

A plane touches down at a busy airport. In 45 minutes, it will take off again. Between landing and departure lies a precisely orchestrated ballet: refueling, catering, cleaning, technical checks, crew handover, baggage handling, and passenger boarding. All of this happens in parallel, all under time pressure. And all of it is documented. Not as an afterthought, but as the core of the operation. We work with an airport where exactly this challenge exists: ensuring that every action during a turnaround is recorded, traceable, and tamper-proof.

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.