Docs

Domain Driven Design

Domain Driven Design 🧩

“Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain.” ― Martin Fowler

Ah, Domain Driven Design. That magnificent approach that promises to turn business chaos into elegant domain models. Do not be fooled by its apparent simplicity, though: it is a bit like trying to teach Italian to a group of penguins. Possible, yes. Immediate, not exactly. 🐧

“The heart of software is its ability to solve domain-related problems for its user.” ― Eric Evans

Foundations of Domain-Driven Design 🏗️

The basis of everything: the domain problem 🎯

Before diving into theory, start with the actual problem: the domain problem. It is the specific problem your software is trying to solve. Not the technical one such as how do I configure Kubernetes?, but the business one such as how do we manage international customer orders?

As Steve Smith put it wisely: As developers, we fail in two ways: we build the wrong thing, or we build the thing wrong. DDD helps reduce both kinds of failure.

Core domain: the heart of the business 💎

“When you focus on the core domain and domain logic, you can push the design of the software to a higher level.” ― Eric Evans

The core domain represents the real differentiating value of a company, the thing that makes it unique and competitive. Everything else, supporting and generic subdomains, exists to support that core. Investing time and care in modeling the core domain well is crucial, because that is where innovation and differentiation actually live.

Identifying the core domain is not always immediate. It often requires digging through business activities and separating what is truly strategic from what is merely operational. A good core domain is one that, if designed badly, puts the entire project at risk.

Modeling and collaboration 👥

Working with domain experts and modeling subdomains 🧑‍💼

DDD starts from an uncomfortable truth: you cannot model well what you do not understand. That is why continuous interaction with domain experts matters. It is not only about gathering requirements. It is about learning to communicate and model together, one subdomain at a time. First rule of DDD Club: you actually need to talk to the domain experts, not just nod while they explain processes that sound like a Kafka novel with more spreadsheets.

Event storming: brainstorming with sticky notes 🌪️
Event storming is a collaborative modeling technique involving the whole team, developers, analysts, and domain experts, in a creative workshop. Colored sticky notes represent events, commands, actors, and rules, helping the team discover domain dynamics quickly and identify bounded contexts. Problems, dependencies, and opportunities often emerge that would have stayed invisible inside a traditional analysis document. To dive deeper: eventstorming.com

Separation of concerns: everyone in the right place 🧹

Separating responsibilities means preventing domain logic from being contaminated by technical or infrastructural details. This principle applies at every level, from code to architecture to team organization. That is how you get a system that remains flexible, testable, and easier to evolve.

For example, data validation should live in the domain, while database connection handling belongs to infrastructure. That separation lets you change technology without rewriting business logic.

Modeling: how to decipher each subdomain 🧩

Modeling is never a linear process. You start from a broader picture, collect stories and use cases, build models, and keep revising them. Techniques such as Event Storming and Event Modeling help visualize processes and reveal hidden rules. Each subdomain should be modeled independently, respecting its boundaries and language.

A useful exercise is asking: if I had to explain this subdomain to a new colleague, which concepts and rules absolutely could not be missing? That usually reveals the key entities and fundamental rules.

DDD patterns and tools 🧰

Ubiquitous language: words, words, words 📚

“A model is not just a knowledge-level description of a domain; it is also the backbone of a language used by all team members to connect their activities with the software.” ― Eric Evans

Ubiquitous language is like the Esperanto of your project, except this one actually works. It should be used everywhere: in code, conversations, and documentation.

As Eric Evans says: A project faces serious problems when its language is fragmented. If your domain expert talks about a quote and your code calls it estimate or proposal in random places, confusion has already moved in.

Bounded contexts: fences with meaning 🏰

Bounded contexts are like sovereign states inside your domain. Each one has:

its own laws, meaning business rules
its own language, meaning ubiquitous language
its own boundaries, meaning defined interfaces
its own passports, meaning context maps

Defining bounded contexts 🏷️

“If the design, or some central part of it, does not map to the domain, then the model is not doing its job.” ― Eric Evans

Defining clear boundaries is often the hardest part of DDD. It requires experience, dialogue, and the ability to recognize when a concept stops being useful in a given context and needs to be reformulated or isolated. A good boundary protects the internal consistency of the model and makes maintenance easier.

A common mistake is assuming that a bounded context always maps to a microservice. It does not. A bounded context is a logical concept and can be implemented inside a monolith just as well.

Context mapping: software diplomacy 🗺️

Context mapping is the art of making bounded contexts communicate with each other. It is like being a diplomat at the United Nations, except instead of preventing wars you are preventing data inconsistency.

The context map shows how bounded contexts connect and interact, supporting collaboration between teams. One warning remains evergreen: sharing a database between unrelated contexts is a reliable way to manufacture misery.

Types of relationships between contexts:

🤝 Partnership: close collaboration between teams
🎭 Customer-Supplier: one-directional relationship
🛡️ Conformist: one context adapts to another
🌐 Shared Kernel: shared code, use with caution
🏗️ Anti-corruption Layer: translate and protect

Ubiquitous language: the language that actually unites 🗣️

Ubiquitous language applies to a single bounded context and should permeate every conversation, model, and line of code. At first it can feel like a terminology exercise, but it is really the key to shared understanding and to avoiding expensive misunderstandings.

Domain layer: the beating heart 🫀

The domain layer is where business rules, entities, value objects, domain services, and aggregates live. That is where the real intelligence of the software resides. Anything related to persistence, communication, or infrastructure should stay out.

A well-designed domain layer lets you test business logic without depending on databases or external frameworks, which makes the system more robust and more adaptable to change.

Aggregates and roots 🌳

An aggregate is a group of objects treated as a single consistency boundary for data changes. The aggregate root is the only external entry point. This pattern helps preserve consistency and simplify business rules.

In an order management system, for example, the order can be the aggregate root and order lines belong to it: no one modifies an order line directly without going through the order.

Value objects vs entities 💎

Entities are like people: they have an identity that persists over time even when they change. Value objects are like numbers: they are defined by their attributes and are immutable.

Entity: mutable object with identity, useful for tracking and persistence.
Value Object: immutable object defined only by its attributes, such as a date. Its logic is usually easy to test and reuse.

Entities, value objects, and domain services 🏷️

Domain services 🏷️

Domain services represent business operations that do not naturally belong to a single entity or value object. They are stateless and often orchestrate multiple domain objects.

A classic example is tariff calculation involving several entities. The logic belongs to the domain as a whole, not to one individual object.

Repository: persistence abstraction 🗄️

Repositories provide an interface to access domain objects without exposing persistence details. This pattern supports separation of concerns and keeps the domain independent from storage technology.

A good repository lets you write unit tests against the domain without configuring a real database, which speeds development and raises quality.

Specification pattern: reusable rules 📏

Specifications are objects that encapsulate validation or selection rules. They are reusable, testable, and help keep business logic out of the persistence layer.

For example, a specification can represent the rule premium customer and be used both to filter data and validate business operations.

Domain events: the business newsroom 📢

Domain events are notifications that signal significant changes in the state of the system. They are essential for integrating bounded contexts and for implementing reactive or event-driven architectures.

A well-designed domain event is immutable, describes something that has already happened, and uses the ubiquitous language of its reference bounded context.

Eventual consistency: patience as an architectural virtue ⏳

In distributed systems, immediate consistency is not always possible or even desirable. Eventual consistency makes it possible to scale and preserve performance, accepting that data will synchronize with some delay.

This approach is especially useful in microservices or systems that must guarantee high availability and resilience.

Anemic domains: the great evil 🧟‍♂️

An anemic domain appears when model classes contain data only and no business logic. It is an anti-pattern that leads to duplicated rules, harder maintenance, and a loss of model meaning. Common causes include excessive ORM or framework influence, forced separation between data and logic, and weak collaboration with domain experts.

The consequences are rarely charming: poor model, rules scattered everywhere, bugs harder to trace, and lower testability.

To avoid it, move business logic back into the domain, collaborate with the people who actually understand the business, and use domain services only for operations involving multiple entities. A rich domain makes the code more expressive, more robust, and easier to evolve.

Practical depth, benefits, and limits of DDD ⚖️🧠

When and why to use DDD

Domain-Driven Design brings the most value when:

the domain is complex and full of business rules
clear communication between teams and stakeholders matters
the project is long-term and maintainability matters
the core problem is domain complexity rather than purely technical complexity

Main benefits:

flexibility in adapting to business change
customer perspective kept at the center
a clear path through complex problems
well-organized and testable code
business logic living in one meaningful place
use of proven patterns such as aggregates, repositories, and specifications

Limits, common mistakes, and when to avoid it

DDD is not the solution to everything. It is better avoided when:

the domain is simple or purely CRUD
the project is small or short-lived
the team lacks time or skills to invest in modeling
the complexity is technical only and not domain-related

Common mistakes:

over-engineering on simple domains
confusing bounded contexts with microservices
not really involving domain experts
building an anemic model with data only
failing to share ubiquitous language between team and code

Advanced strategies and practical advice

Strategic vs Tactical Design: start with strategy, boundaries, language, and relationships, and only afterward move into tactical details such as entities, value objects, and repositories.
Anti-Corruption Layer (ACL): protect your model by translating data between different bounded contexts.
Event Sourcing and CQRS: useful only in complex domains where they bring real value.
Testability: separate domain logic from infrastructure to test rules more easily.
Culture and team: DDD works only with ongoing collaboration between developers and stakeholders, plus a culture of discussion and constant revision.

In short

DDD is a powerful toolbox: use it where it truly helps, involve domain experts seriously, and do not be afraid to revise the models as the business evolves. It is not a magic wand, but when applied with judgment it brings clarity, robustness, and a certain quiet satisfaction, much like a properly made espresso.

FAQ and myths about DDD ❓

Is DDD only for large companies? No, but it shines most in complex domains and long-term projects. In simple or short-lived projects it can easily become excessive.

DDD equals microservices? No. Bounded contexts are logical concepts, not automatically microservices. You can apply DDD inside a monolith very effectively.

Do I always need Event Sourcing or CQRS? No. They are advanced patterns and should be used only when they bring clear benefits. The heart of DDD is domain modeling, not technology theatre.

Is DDD too complicated? DDD requires effort, yes, but it exists to handle complexity. You can adopt it gradually, starting with ubiquitous language and collaboration with domain experts.