What is Domain-Driven Design?
What is Domain-Driven Design? A beginner's guide to the software discipline.
What is Domain-Driven Design?
Domain-Driven Design (DDD) is an approach to designing software around the business it serves. It's part philosophy, part toolkit: a way of thinking about software design, backed by concrete patterns and practices.
A core promise of DDD is that it helps you deal with complexity in a more sustainable way. It helps you build a system that not only solves today's problems but is malleable enough to adapt to tomorrow's. Every software system carries two kinds of complexity. Essential complexity comes from the business domain itself: the rules, exceptions and processes you can't wish away. Accidental complexity is everything we add along the way: tangled code, unhelpful abstractions and structures that made sense once. DDD's focus on domain modelling makes the essential complexity explicit, so you can see the accidental complexity for what it is and remove it. The result is a system you can keep evolving at a fast pace.
Unlike most software design methods, DDD looks at the whole system. At the micro level, that means individual pieces of code and design patterns. At the next level up, it covers code organisation, domains, Bounded Contexts and architecture. And at the largest scale, it shapes how systems and teams integrate across an organisation.
DDD was coined by Eric Evans and popularised through his 2003 book, Domain-Driven Design: Tackling Complexity in the Heart of Software, often referred to as the Blue Book. It comes with a pattern catalogue: a coherent set of patterns that good software designers were already practising, which DDD names and explains. It also introduced genuine innovations, such as Bounded Contexts. Above all, DDD gives teams a shared vocabulary for talking about software design.
DDD has a rich body of principles and patterns, so here we'll outline the core concepts a beginner needs.
Domain Modelling
"A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem."
Eric Evans
Author of Tackling Complexity in the Heart of Software
To deal with complexity, DDD advises you to create and evolve models of the business domain. You build these models together with domain experts, and they become the basis for the code, the tests, the documentation, the user interfaces and the conversations about the domain. Compared with the purely technical models we find in most software, they encode and preserve far more knowledge about the business. That keeps the complexity understandable and manageable, which makes future changes easier and faster.
Think of a domain model the way a scientist thinks of a scientific model. A great model is contextual: a set of useful abstractions for the problem at hand. And as in science, a great model gives you predictability. You can predict how the system will behave, and how to change it without breaking it.
In Eric Evans' popular keynote at Domain-Driven Design Europe in 2019, Evans argues that "by choosing a model that is well suited for a particular problem you want to solve, you can make the computation simpler."
Since Eric Evans' book, the community has developed several modelling techniques closely associated with DDD. The best known is Alberto Brandolini's EventStorming, a workshop format where developers and domain experts map out a business process with sticky notes. Others include Domain Storytelling and Example Mapping.
Ubiquitous Language
In any social group, like a team, department or company, a language evolves to fit the group's needs. That language is organic, always in motion, often messy and ambiguous. That's normal; it's how natural language works. But when we design systems, we need language to be precise and unambiguous.
A Ubiquitous Language is a deliberately designed language, based on the domain, that engineers and business stakeholders use to talk to each other in precise terms. We use the same language in the code and other artefacts, which keeps our systems understandable in the long term. At its best, the Ubiquitous Language is used so consistently that a non-technical domain expert could read the code, understand what it does and spot mistakes. Even without going that far, a shared language makes conversations about the software much smoother, and the resulting software fits the business far better.
Read our full guide to Ubiquitous Language for more details
Bounded Contexts
To manage complexity, we need to split our software and its models into smaller units. Traditionally, we've done that with technical separation: components, modules and (micro-)services.
DDD does it differently. You look at the domain language and the models first, and draw boundaries around those. Within each Bounded Context, the language and the model are consistent and unambiguous. We don't attempt a single universal model across the organisation; that doesn't work, and it comes with a high coordination cost. Smaller, independent models can be much better aligned with business needs, and can keep evolving to meet them.
Take the word "customer". To Sales, a customer is a lead with a budget, a decision-maker and a pipeline stage. To Support, a customer is someone with an account, a contract and a history of tickets. Forcing both meanings into one model gives you a bloated object nobody fully understands. Two Bounded Contexts, each with its own precise meaning of "customer", keep both models clean.
A useful way to build intuition: a Bounded Context is an understandability boundary. It groups concepts that need to be understood together, and separates them from unrelated ones. That makes teams productive, because a new team member can learn a small Bounded Context quickly without wading through unrelated concepts.
In practice, you'll still separate code into modules or services. But that separation will follow the real business domain, rather than technical or organisational concerns.
Read more about Bounded Contexts
Core domain and subdomains
Not every part of your software deserves the same attention. DDD asks you to split the business domain into subdomains, and to be honest about which ones matter most.
Core domain: what makes your business different and gives it a competitive edge. This is where your best people and your most careful modelling should go.
Supporting subdomains: necessary for the business and specific to it, but not a differentiator. Build them well enough, without gold-plating.
Generic subdomains: problems every business has, like invoicing, authentication or email delivery. Buy them or use an off-the-shelf solution wherever you can.
This is arguably DDD's most important strategic idea. Many teams spend enormous effort on generic problems while the part of the system that actually earns money stays a tangle. Knowing your core domain tells you where to invest.
Strategic and tactical design
DDD works at two levels, and it helps to know which one you're looking at.
Strategic design is about the big picture: identifying subdomains, drawing Bounded Contexts, and mapping how those contexts relate to each other (context mapping). It answers questions like "Where should the boundaries be?" and "Which team owns what?"
Tactical design is about building the model inside a single Bounded Context. It gives you building blocks such as Entities (objects with an identity that persists over time), Value Objects (objects defined only by their attributes, like an amount of money) and Aggregates (clusters of objects that are changed together and keep their own business rules consistent).
Many teams start with the tactical patterns because they're closest to the code. The bigger payoff usually comes from getting the strategic design right first: well-placed boundaries make everything inside them easier.
Why use Domain-Driven Design?
A core benefit of a mature DDD system is that your code and artefacts look like the problem you're solving. The code uses the same language as the business stakeholders, and the shared model expresses business concepts, behaviours, rules, processes and relationships. Adding a new business rule becomes straightforward: it's obvious where it fits, and its impact is predictable.
A clear model, language and boundaries let you move faster. You don't waste time reverse-engineering what the code is supposed to do, because it communicates its intent. Teams often underestimate how much faster they can respond to market changes and customer demands once they work this way.
DDD and AI
Martin Fowler
Chief Scientist at Thoughtworks
Practising Domain-Driven Design means deeply understanding the domain and the problems you’re trying to solve. The outcomes, such as a shared ubiquitous language and well-defined bounded contexts help your team and organisation evolve faster. But there’s real value in the process too. The learning that happens while you build these artefacts gives your team deeper domain knowledge, and that knowledge pays off long after the model is drawn. AI can sometimes build these artefacts more quickly, but often the process of learning is skipped. Coding agents have made writing code trivial. Shipping software that meets customers’ needs still requires a deep understanding of the domain and what the business actually needs.
Katharina Damschen
Speaker at Domain-Driven Design Europe
When is DDD not worth it?
Building an in-depth model takes time with domain experts, and the concepts take a while to learn, so it pays to be selective.
Simple CRUD applications. If your software mostly stores and retrieves data with few business rules, a rich domain model is overkill.
Generic problems. Don't model invoicing or authentication from scratch when a proven product exists. Save your modelling effort for your core domain.
Throwaway software. A prototype that will live for three months doesn't need carefully drawn Bounded Contexts.
DDD isn't all-or-nothing. Even in simpler systems, a shared language and sensible boundaries pay off. The heavier techniques are for the parts of your system which are core and complex.
Frequently asked questions
Is DDD only for microservices? No. DDD predates microservices by about a decade. Bounded Contexts are a good guide for where to draw service boundaries, but they work just as well as modules inside a single, well-structured monolith.
What books should I read? Eric Evans' book is the foundation, but it's dense. Many people start with shorter introductions, talks or a hands-on workshop, then return to the Blue Book once the core ideas have clicked.
What's the difference between a domain and a Bounded Context? The domain, and its subdomains, describe the business problem space: what the business does. A Bounded Context is a design decision in the solution space: a boundary within which one model and one language apply. Ideally they align, but they don't have to map one-to-one.
Can I apply DDD to an existing legacy system? Yes, and that's where many teams start. Strategic design helps you find the boundaries hidden in a legacy system, so you can untangle it step by step instead of rewriting it all at once.
Getting started with DDD
The fastest way to learn DDD is to apply it to your own domain, with someone who has done it before. We help teams get started through hands-on training and consulting, from a first EventStorming session to untangling a legacy system. Book a short call to talk about where DDD could make the biggest difference for you.
Want to keep learning on your own?
Read the original: Eric Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software.
Go deeper into shared language with our guide to Ubiquitous Language.
Meet the community at DDD Europe, the yearly conference for domain-driven design practitioners.