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.

When Everyone Speaks a Different Language

Ask five people in the DDD community what the difference is between a command and an intent, and you'll get five different answers. Some treat them as synonyms. Others insist they're fundamentally different concepts, with commands being concrete instructions and intents being abstract expressions of desire. Both camps have reasonable arguments. Neither camp seems particularly interested in settling the matter.

The same confusion extends to events. Is there a meaningful difference between an "event" and a "domain event"? Some practitioners use the terms interchangeably. Others draw a hard line: a domain event captures something that happened within a bounded context, while an "event" is a broader, more generic concept that includes infrastructure concerns. The distinction matters in practice, because it changes how you design your system boundaries. But good luck finding two blog posts that use the terms in exactly the same way.

Then there are projections. Or read models. Or views. Three terms for what is, depending on who you ask, either the same thing or three subtly different concepts. Some authors use "projection" to mean the process of deriving state from events, while "read model" refers to the result. Others use "projection" and "read model" interchangeably but reserve "view" for something user-facing. And others still treat all three as perfect synonyms. If you're new to Event Sourcing, this is bewildering. If you're experienced, you've probably just picked one term and stopped worrying about it.

The classic example, though, is the saga versus process manager distinction. Originally, the term "saga" referred to a specific pattern for managing long-running transactions with compensating actions. A process manager, by contrast, orchestrates a workflow by reacting to events and issuing commands. These are different concepts with different responsibilities. But over time, the community started using "saga" for everything, until the original meaning became so diluted that most developers today couldn't tell you what distinguishes one from the other. The definitions exist. They're clear. But too few people know them, and too many use the terms loosely, in a "you know what I mean" fashion.

And here's the meta-irony that ties it all together: even the term for the shared language isn't used consistently. Eric Evans called it the Ubiquitous Language, a term chosen deliberately. "Ubiquitous" means everywhere, always, without exception. It's not a "shared" language, where two parties happen to overlap. It's a language that permeates every conversation, every document, every line of code. Yet you regularly hear and read "shared language" used as if it were the same thing. A community that exists to champion precise language can't even be precise about the name of its most fundamental concept.

The problem isn't that the definitions don't exist. They do. The problem is that too few people know them, and the rest have gotten comfortable with imprecision. "You know what I mean" is the exact opposite of what DDD stands for. The Ubiquitous Language isn't about rough understanding. It's about naming things precisely, because imprecise names lead to imprecise thinking, which leads to imprecise software.

Books That Failed Their Own Promise

Part of the terminology problem traces back to the very books that defined the field.

Eric Evans' Blue Book, "Domain-Driven Design: Tackling Complexity in the Heart of Software," is considered the foundational text. And Vaughn Vernon's Red Book, "Implementing Domain-Driven Design," is its most prominent companion. Both are serious works by serious thinkers. Both contain genuinely valuable ideas. And both are, for the majority of developers, nearly impenetrable.

This isn't about intelligence. It's about communication. DDD is, at its core, a methodology about understanding. It asks you to understand the business domain, understand the language of domain experts, understand the boundaries between contexts. The entire premise of DDD is that understanding is the foundation of good software. And yet, the books that introduced this methodology to the world are written in a style that actively works against understanding.

The Blue Book is dense, abstract, and academic. It uses jargon to explain jargon. It introduces concepts through layers of abstraction rather than concrete examples. Many developers, myself included, have read it multiple times and still come away feeling like they missed something essential. The Red Book improves on this with more code examples, but it adds so many layers of technical infrastructure that the core ideas get buried under implementation details.

As we discussed in If You Apply DDD to DDD, You Won't Get DDD, this is more than just a stylistic failing. If you actually apply DDD's own principles to DDD, if you ask "What is the domain? What matters? What can we strip away?", you don't end up with what we call "DDD" today. You end up with something much simpler. A methodology that's supposed to make complexity manageable has itself become unmanageably complex.

The consequence is that most developers encounter DDD through secondary sources: blog posts, conference talks, YouTube videos. Each of these interprets the source material through the author's own lens, emphasizing different concepts, using slightly different terminology, simplifying in different ways. This isn't inherently bad, interpretation and adaptation are natural. But when the primary sources are already unclear, the secondary interpretations diverge wildly. And that divergence compounds over time, creating a landscape where ten different authors teach ten different versions of DDD, all claiming to be faithful to the original vision.

A Pattern for Every Season

The terminology problem is compounded by a deeper structural fragmentation: the community can't agree on the fundamental building blocks.

Take the aggregate, arguably the most discussed concept in DDD after Bounded Context. In the original formulation, an aggregate is a cluster of domain objects that can be treated as a single unit, a transactional boundary that ensures business rules hold. For years, this was the canonical pattern. You define your aggregates, you enforce consistency within them, and you accept eventual consistency between them. Clear enough.

Then came the critique. Aggregates are too rigid. Their boundaries are static, defined at design time, but business requirements evolve. What was one aggregate sometimes needs to split. What were two sometimes needs to merge. Cross-aggregate operations require Sagas or Process Managers, turning simple business logic into complex infrastructure. The aggregate pattern, meant to simplify, had become a source of accidental complexity.

So Sara Pellegrini proposed Dynamic Consistency Boundaries, or DCBs. Instead of fixed boundaries defined by aggregate classes, you define boundaries dynamically per operation. You query exactly the events you need, lock exactly what you need, no more, no less. The promise: more flexibility, less infrastructure, operations that naturally match business requirements instead of fighting them.

Meanwhile, Frank Scheffler and the OpenCQRS project went in yet another direction, advocating for a "No Aggregate" approach that deliberately avoids the aggregate pattern altogether. Not "Kill Aggregate" in the DCB sense, but "No Aggregate" as a design philosophy: lightweight, flexible, deliberately unstructured where structure adds more cost than value.

Three approaches, three camps, three sets of tradeoffs. Traditional aggregates with transactional boundaries. DCBs with consistency boundaries defined dynamically. No aggregates at all. Each has thoughtful proponents. Each solves real problems. Each introduces its own risks. And a newcomer looking at this landscape has no way to know which one to start with, because the community doesn't offer a default path. It offers a debate.

The same fragmentation plays out in modeling methods. Event Storming, created by Alberto Brandolini, uses sticky notes on a wall to explore a domain. Event Modeling, developed by Adam Dymitruk, emphasizes visual swim lanes and time-based flows. Domain Storytelling uses pictographic notation to capture domain narratives. Each method has its practitioners, its conferences, its body of literature. Each claims to be the best way to discover a domain. And each produces slightly different artifacts, slightly different vocabularies, slightly different ways of thinking about the same problems.

The Example Nobody Shares

Beyond terminology and methodology, there's an even more basic gap: the community lacks shared examples.

Think about how the relational database world handles this. When you learn SQL, you encounter standardized example databases. Northwind. Sakila. AdventureWorks. These aren't just sample data. They're shared reference points. When someone explains a join strategy using Northwind, every other SQL developer knows exactly which tables and relationships they're talking about. The example is a common language in itself.

The DDD and Event Sourcing community has nothing comparable. Every author, every speaker, every workshop facilitator invents their own example domain. One uses a library system. Another uses e-commerce. A third uses hotel booking. A fourth uses banking. A fifth uses healthcare. The examples are endless, but none is canonical. None is shared. There's no equivalent of Northwind for Event Sourcing.

This matters more than it might seem. When everyone uses different examples, you can't compare approaches. If one author models a library system with aggregates and another models a hotel booking system with DCBs, how do you evaluate the tradeoffs? The differences between the approaches are entangled with the differences between the domains. You're comparing apples to oranges and trying to draw conclusions about fruit.

But the deeper problem is documentation. Most example domains in the DDD world are sketches, barely more than the event names and a rough structure. What's almost always missing is the reasoning. Why was this modeled as two separate aggregates instead of one? Why is this event on this subject and not that one? Why did we choose eventual consistency here but strong consistency there?

The interesting thing about a domain model is rarely what it looks like. It's why it looks that way. The decisions, the tradeoffs, the rejected alternatives, the edge cases that forced a particular structure. Without that reasoning, an example domain is just a diagram. It shows you what someone built but doesn't teach you how to think.

One notable exception deserves mention: Vaughn Vernon's "Effective Aggregate Design" series (Part 1, Part 2, Part 3). These articles don't just show you an aggregate design. They walk you through the reasoning, the constraints, the tradeoffs, the evolution of the model. They explain not just "what" but "why." It's a model for how examples should be documented. And yet, more than a decade later, it remains almost the only example of its kind. The community produced one excellent reference and then stopped.

The Cost of Fragmentation

All of this, the inconsistent terminology, the inaccessible books, the competing approaches, the lack of shared examples, adds up. And the cost is paid primarily by the people we should care about most: newcomers.

Imagine you're a developer who's heard that Event Sourcing might solve some of your problems. You start reading. The first blog post talks about aggregates as the natural unit of consistency. The second blog post says aggregates are the problem and you should use DCBs instead. The third says forget both, just keep it simple and don't use aggregates at all. The first uses the term "projection," the second says "read model," the third says "view." They all seem to be saying different things, but are they actually? Or are they saying the same thing in different words? You can't tell, because there's no shared vocabulary to anchor the discussion.

You try the books. The Blue Book is 500+ pages of dense theory. You understand the big picture, sort of, but the details swim. You try the Red Book. It's more practical but drowns you in implementation details for frameworks you don't use. You look for example projects. You find dozens, each in a different language, each using a different architecture, each modeling a different domain. None of them explain why they made the choices they made.

This is why, as we explored in Introducing DDD to Your Organization, the biggest challenge isn't technical. It's cultural. It's getting people past the initial wall of confusion and showing them that the core ideas are simpler than they appear. But the community's fragmentation makes that wall higher than it needs to be.

Conference talks illustrate the problem perfectly. Two speakers at the same conference can use the same term with different definitions, and neither feels the need to clarify, because within their own context, their usage is consistent. The audience, hearing both talks, walks away confused. Not because either speaker was wrong, but because the community lacks a shared baseline. There's no "standard DDD" to deviate from, only competing interpretations of a 23-year-old book that was itself hard to understand.

Brilliance Without Bridges

None of this is an indictment of the individuals involved. The people working in this space, the authors, the speakers, the framework builders, the practitioners, are thoughtful, passionate, and genuinely trying to advance the state of the art. The problem isn't a lack of brilliance. The problem is a lack of bridges.

The DDD and Event Sourcing community has produced an extraordinary body of thought. Deep insights about domain modeling, elegant solutions to consistency problems, innovative approaches to system design. But this body of thought is fragmented across dozens of blogs, books, talks, and frameworks, each using slightly different language, each assuming slightly different foundations, each building on slightly different examples.

Diversity of thought is valuable. The tension between aggregates and DCBs has produced real insight. The debate about Event Storming versus Event Modeling has sharpened both approaches. Competing perspectives make the field richer. This isn't about finding the One True Way or suppressing disagreement. Healthy communities disagree, vigorously and productively.

But there's a difference between productive disagreement and accidental fragmentation. Productive disagreement happens when people understand each other's positions and choose to differ. Accidental fragmentation happens when people don't realize they're using the same word for different things, or different words for the same thing. The first advances knowledge. The second wastes everyone's time.

Right now, the DDD and Event Sourcing community has too much of the second kind. Not because anyone intends it, but because the infrastructure of shared understanding, the common vocabulary, the canonical examples, the accessible introductions, simply hasn't been built. The brilliance is there. The bridges aren't.

Whether that changes is up to the community. This post isn't a call to action, and it's not a manifesto. It's an observation. A recognition that the people who care most about shared understanding in software development have, paradoxically, not yet achieved it within their own discipline. And that recognizing the problem might be the first step toward something better.

If you're curious about the core ideas behind DDD and Event Sourcing without the pattern overload, DDD: Back to Basics is a good place to start. And if you'd like to share your perspective on any of this, we'd love to hear from you at hello@thenativeweb.io.