Skip to content

Perspectives

How Can I Force Myself to Stop Thinking in Technical Solutions?

Henry Ford is often quoted as having said, "If I had asked people what they wanted, they would have said faster horses." The line is probably apocryphal, but the picture it paints is accurate. People describe solutions, not problems. They say "I need a queue" when what they mean is "things keep getting lost between two systems." They say "we need a microservice" when what they mean is "this part of the codebase is painful to deploy." The technical answer arrives before the question is even formed, and that is true for product owners, business stakeholders, and developers alike.

This is the trap every thoughtful developer eventually wants to escape. After a few years, you start to notice that the systems you build are answering the wrong questions. You read about Domain-Driven Design, you learn the words "ubiquitous language" and "bounded context", and you decide that from now on, you'll think about the business first and the technology second. Then you walk into your next meeting, and within ninety seconds you're already drawing tables on the whiteboard. You wanted to stop. You couldn't. This post is about why, and about the only thing we've actually seen work.

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.

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.

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.

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."

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.

It Was Never About the Database

We build a database. We spend our days thinking about storage engines, query languages, and wire formats. We obsess over write throughput, replay performance, and consistency guarantees. This is what we do, and we care deeply about getting the technical details right.

But when we look back at the most impactful conversations we've had with teams adopting Event Sourcing, they were never about technology. They were about how people work together. About how a team that had been talking past each other for months suddenly found a shared vocabulary. About how a business process that had been invisible for years became something everyone could see, discuss, and improve. That is the story we want to tell today.

Consistency Is a Business Decision

You have probably heard of eventual consistency. The short version: in a distributed system, when data changes in one place, other parts of the system might not see that change immediately. For a brief moment, different components have different views of the truth. Eventually, they all catch up. Eventually, they all agree. But not instantly.

This concept makes many developers nervous. "Eventually consistent" sounds like "temporarily wrong." It sounds like a bug waiting to happen. In German, it gets even worse: "eventual consistency" is often translated as "eventuell konsistent," which means "possibly consistent," implying the data might never be correct. No wonder people reach for stronger guarantees.

But "eventual" in English means "ultimately" or "in the end," not "possibly." Eventual consistency means the system will become consistent, given enough time. The question is not whether consistency happens, but when. And here is the uncomfortable truth: your system is already eventually consistent. You just have not admitted it yet.