Domain-driven design

Concept · Chapter 3

The idea in brief

The domain is the subject and body of knowledge the software will be applied to.
Domain-driven design (DDD) — coined by Eric Evans (Domain-Driven Design: Tackling Complexity in the Heart of Software) — improves software by focusing on the domain, with a set of proven concepts and patterns.
Most valuable for large applications with complex, sizable models. Even if you don’t adopt DDD fully, individual concepts are useful and recur elsewhere in architecture work.

Encourages and improves communication

DDD stresses communication among all team members and, in particular, interaction with domain experts.
A domain expert / subject matter expert (SME) is an authority in a particular area who helps the whole team understand the domain.
The main communication device DDD introduces is the ubiquitous language.

Ubiquitous language

The problem: developers describe the domain in technical/design terms; stakeholders use their own jargon. Different words for the same concept slow communication and cause misunderstandings. Team members who learn both “dialects” become translation bottlenecks, and translation itself weakens knowledge sharing.

The solution — a ubiquitous language: a single common language, shared by all team members and stakeholders, based on the domain model.

It evolves and grows as the team’s understanding of the domain deepens.
Domain experts flag terms that don’t express an idea correctly; everyone hunts for inconsistencies and ambiguities.
Once established, no translation is needed. The key discipline is to use it consistently everywhere: discussions, documentation, diagrams, code, and tests.

Tactical building blocks

When modeling these, always use the ubiquitous language.

Block	Identity?	Mutability	Equality	Example
Entity	Defined by identity, not attributes	Mutable (attributes change, identity doesn’t)	Not equal even with identical attributes (differ by unique id)	Two `Person` objects, same name, still distinct
Value object	No identity	Immutable	Equal when all attribute values match	A Cartesian point `(x, y)`
Aggregate	A grouping treated as one unit	—	—	An `Order` containing an address and line items

Aggregates define a boundary around a cluster of entities and value objects, retrieved and saved as a single unit.
A designated root entity is the entry point. Without aggregates, large models become unwieldy and saving an object plus all dependents becomes error-prone.

Strategic partitioning

Subdomains (partitions of the domain)

A domain is the entire problem space; a subdomain is a partitioned piece of it.
Splitting reduces complexity — a divide-and-conquer approach for large domains.
Example (student information system): contact management, admissions, financial aid, student accounts, academics.
A core domain is a subdomain fundamental to the organization — the part that differentiates it from competitors and the reason the software is worth building rather than buying off the shelf or outsourcing. Domain experts help identify core domains and the division into subdomains.

Bounded contexts (partitions of the domain model)

A domain model is a conceptual model of the domain including both behavior and data.
A bounded context is an explicit partition/boundary within the domain model. Similar to subdomains but at the model level; a bounded context may map to a single subdomain, but not always (a subdomain can need several).
Why: the same term can mean different things in different parts of the system. Explicit contexts clear up ambiguity about what is shared vs. unique.
Example (online clothing store): a Marketing Context (newsletter/deals) and an Order Processing Context (orders/payment). Both share a Customer concept — but Marketing needs only id, name, email, while Order Processing also needs shipping address and payment info.
Using one Customer across contexts adds complexity and inconsistency (payment validation only applies in Order Processing), and would make the entity take on too many responsibilities — violating the single responsibility principle.
Each context should have a clearly defined, explicit boundary so all teams share the same understanding of what belongs where.

Fits with microservices

DDD and bounded contexts align well with microservice architecture — the context boundaries map naturally onto service boundaries.

Citations

Software Architect’s Handbook (Packt, 2018), Ch.3 “Domain-driven design”, pp. 141-153.