阅读中文版本

Domain-Driven Design

Domain-driven design centres modelling on the business domain and a shared ubiquitous language, aligning code structure with how experts describe the problem.

Definition

Domain-driven design is an approach to software development that focuses effort on modelling the core domain, using a language shared by developers and domain experts as the basis for the model and the code.

It is applied to complex business domains where the main difficulty is understanding and expressing rules, not technical infrastructure. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Strategic design identifies the core, supporting, and generic subdomains and draws boundaries so that each can be modelled in the terms that best fit it.

The ubiquitous language must appear in code as well as conversation, because a translation gap between the two reintroduces the misunderstanding the approach tries to remove.

Trade-offs and alternatives

Tactical building blocks such as entities, value objects, and aggregates implement the model inside a boundary; applying them without the strategy yields ceremony without insight. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that DDD always implies microservices. Another is that a rich domain model is mandatory for every part of a system. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to applying tactical patterns such as entities everywhere without strategic modelling and to letting database tables define the domain model. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Bounded Context, Aggregate Root, Repository Pattern.