Understanding Domain-Driven Design
More than two decades have passed since Eric Evans published Domain-Driven Design: Tackling Complexity in the Heart of Software, the work that launched the DDD movement. The book continues to sell well, and a thriving community has expanded DDD considerably: international conferences are held regularly, new books and courses appear, and practitioners keep introducing fresh concepts.
Different authors and speakers approach DDD from various angles, but here I want to examine what lies at its very heart.
The intention is to
- clarify where DDD puts its emphasis,
- explain why misconceptions about it have spread,
- look at how it connects to object-oriented programming,
- and consider whether it can work with other paradigms.
For the most part, I'll draw on Eric Evans' own interviews and conference talks. To round things out with concrete examples, I'll also point to other sources. Before diving in, a brief primer on DDD will make sure everyone is on the same page.
Many thanks to Eberhard Wolff for taking the time to review this piece!
A Quick Overview of DDD
At its core, Domain-Driven Design is about gaining a thorough understanding of the real-world domain — the problem space — that a software system serves. Domain experts, such as people who know invoicing inside out, collaborate closely with software professionals to craft models of that domain. A model captures the parts of reality — concepts, connections, and workflows — that matter for the software at hand, and these models find their way directly into the source code.
Strategic Design
The original DDD framework splits into two parts. The first, Strategic Design, involves identifying subdomains, each representing a distinct slice of the problem domain. These subdomains get their own bounded contexts, and within each bounded context there is a model tied to an Ubiquitous Language. That language mirrors the vocabulary people use in the real world, adopted by both domain experts and developers alike — when they talk, when they write, in diagrams, and in code.
Opting for several smaller models instead of one all-encompassing system-wide model leads to representations that better fit each subdomain. At the same time, this approach keeps coupling loose and complexity manageable.
Consider the illustration below: two bounded contexts, each with its own take on what a product is, and thus each with a distinct representation:
Tactical Design
Strategic Design gives you the high-level architecture, while Tactical Design supplies the building blocks for implementing the model inside each context. Among these are Value Objects and Entities, Aggregates that capture whole-part hierarchies like an Order with its Order Lines along with consistency rules, and repositories that handle persistence for aggregates and entities.
Newer Ideas in DDD
Since the original book, various concepts have joined the DDD toolbox. Domain Events are one example — they are now considered part of DDD even though Evans did not explicitly describe them originally.
Another addition is Collaborative Modelling, a practice that emerged over the years. It offers workshop techniques such as Event Storming and Domain Story Telling, which bring domain experts and software specialists together to explore a domain collaboratively.
Strategic Design has also found its way into other communities. The Microservice movement uses it to draw boundaries between services, and the Micro Frontend community has adopted it as well. Beyond distributed systems, it applies to monolithic architectures, and there is ongoing discussion about using Strategic Design with Event Storming for modular Frontend Monoliths.
Team Topologies is yet another recent movement that builds on the Bounded Context as a basis for splitting systems into parts that separate teams can own.
Further Reading on DDD
For more detail, check the linked blog posts above. If you'd rather watch than read, there is an excellent talk on Strategic Design available here, and a discussion about prioritizing bounded contexts that introduces the idea of a Core Domain over there.
Defining DDD
In his keynote titled "DDD Isn't Done" at Explore DDD 2018 in Denver, Eric Evans talked about how to characterize DDD. He emphasized finding the right balance so DDD can genuinely lead to "valuable software." Pin the definition down too tightly and it turns into a "trivial cookbook"; leave it too loose and it becomes "handwavy good advice" — neither serves anyone well.
His own take adds another layer:
We need some room to move. Different people need to be able to operate in a space and have different views and innovate.
For Evans, DDD boils down to a few guiding principles:
- Put the core domain first.
- Build models through collaboration between domain practitioners and software practitioners.
- Use a ubiquitous language within a explicitly bounded context.
When Does It Count as DDD?
The definition just discussed matches what Eric Evans said during an Interview with InfoQ. When asked what minimal practices a team must adopt to be doing DDD effectively, he pointed straight to Ubiquitous Language and the Bounded Context:
[...] the most fundamental pattern of Domain-driven Design is probably the ubiquitous language. [...]
[A model] applies within a certain context, and that context has a definitely defined limit, [it's] a bounded context.
With those two ingredients, I would say, someone is doing Domain-driven Design, and there are a lot of other practices that help solve more specific problems.
Misplaced Emphasis in DDD
In an interview with the IEEE Computer Society marking DDD's 10th anniversary, the question came up: what would Evans change if he rewrote his book? Rather remarkably, he believes many readers walked away with the idea that DDD is mainly about Tactical Design's building blocks. In reality, he argues, the heart of DDD sits in Strategic Design:
[...] all the strategic design stuff is way back at the back. [...] it's so far back that most people never get to it really.
Another thing I would do is try to change the presentation of the building blocks [...] things like the entities and value objects [...] [People] come away thinking that that's really the core of DDD, whereas, in fact, it's really not.
I really think that the way I arranged the book gives people the wrong emphasis, so that's the biggest part of what I do is rearrange those things.
Yet Tactical Design should not be dismissed, he adds, because it serves as the bridge from a conceptual model to working code.
Evans makes a similar point in his keynote at DDD Europe 2016, lamenting the "over-emphasis on building blocks."
Object-Oriented Tactical Design? Room for FP?
In the same keynote, Evans made clear that DDD does not belong to any single programming paradigm. He noted that Functional Programming can serve as a "powerful mechanism for abstraction" and that functional languages are well-suited for expressing a model directly in code.
He also observed that contemporary languages tend to be more expressive than their predecessors, which helps developers implement models more concisely. Libraries such as Reactive Extensions can add another layer of expressiveness.
Asked about FP in light of his book's strong object-oriented flavor, Evans responded, in the IEEE Computer Society interview, that the choice was simply a product of its time:
The reason that everything is expressed in terms of objects is because objects were king in 2003-2004, and what else would I have described it as people [...] used objects.
He does, however, see the need for adjustments when applying Tactical Design to FP:
If you are going at it from a functional point of view, then [...] your implementations are going to look quite different.
Elsewhere in the keynote, he reiterates that moving to FP requires "rethinking [...] building blocks."
This need for adaptation gets some attention in Vaughn Vernon's Domain-Driven Design Distilled, a widely respected and accessible reference in the DDD world. Vernon explains that in functional DDD, business logic finds its home in pure functions, while data structures take the form of Immutables, or records:
Rather than modifying the data that functions receive as arguments, the functions return new values. These new values may be the new state of an Aggregate or a Domain Event that represents a transition in an Aggregate's state.
For those interested in going deeper, Functional and Reactive Domain Modeling and Domain Modeling Made Functional are both worth a look.
Evolving Tactical Design Beyond the Original Patterns
Eric Evans has revisited how Tactical Design patterns can be reshaped for alternative paradigms, pointing to event sourcing and CQRS as prime examples. These concepts were never part of the original DDD framework, yet the community adopted them organically. In the same discussion, Evans also highlights the actor model as a viable means of implementing Aggregates:
[An actor] can maintain that state in a consistent [...] way [...] that respects the invariance of that particular aggregate. [...]
This line of thinking connects directly with the widely circulated conference talk "The Aggregate is dead. Long live the Aggregate!". In it, Milan Savić and Sara Pellegrini question traditional Aggregate implementations and propose a messaging-based approach supported by event sourcing.
More broadly, these kinds of extensions align with Evans's 2018 keynote, where he urges the community to experiment and push the boundaries of DDD creatively.
At DDD Europe 2016, Evans also introduced two additional modeling paradigms applicable to DDD:
- Relational
- Graphs
Relational modeling may seem counterintuitive at first. Evans does not advocate for a single, fully normalized database schema, which would clash with the idea of bounded contexts. Rather, he suggests several specialized schemas that align with DDD's core philosophy. On top of that, he considers SQL a practical vehicle for expressing set-based comparisons and manipulations.
When Evans mentions graphs, he goes beyond simply recommending a graph database. He frames graph theory as a long-standing modeling approach, originating well before computer science as a discipline. For him, representing certain problem types through nodes and edges fits naturally into the DDD toolkit.
Wrapping Up
The heart of DDD lies in the collaborative exploration of a domain by both Domain Experts and Software Experts, who together shape focused bounded contexts and share a common ubiquitous language.
The Tactical Design patterns introduced in the original DDD book provide a solid foundation for implementing those models using object-oriented techniques. Still, alternative routes and modifications exist, for instance within Functional Programming circles.
Several communities limit their adoption to Strategic Design—think Micro Services, Micro Frontends, or Team Topologies—and use it mainly to carve a system into segments that follow domain boundaries.