Domain-Driven Design: Tackling Complexity in the Heart of Software
Source: https://www.informit.com/store/domain-driven-design-tackling-complexity-in-the-heart-9780321125217 ↗
Evans's argument is that software which resists maintenance is usually software whose model has drifted from the business it is meant to represent.
The cure is ubiquitous language — the same words in code, in meetings and on whiteboards — and bounded contexts where models are allowed to differ without pretending they agree.
For product direction this is the clearest technical articulation of why vocabulary matters.
When a team says "user" and means four different things in four different meetings, no amount of planning will save the codebase.
Domain-Driven Design gives a discipline for noticing that drift before it becomes structural.
Central argument
Evans argues that software becomes hard to maintain not primarily because of poor engineering practices but because the code model drifts from the business domain it is meant to represent. The remedy is a ubiquitous language — identical terminology enforced across conversations, diagrams, and source code — and bounded contexts that acknowledge different parts of an organization legitimately hold different models of the same concept rather than forcing false unification. The central claim is that complexity is not a technical problem to be abstracted away but a modeling problem that must be confronted directly by aligning how the domain is spoken about with how it is encoded.
Critique
DDD was designed for large, complex domains built by teams with sustained access to deep domain experts, and Evans largely assumes that relationship is achievable — a significant assumption in product environments where subject-matter expertise is fragmented, contested, or changes faster than a model can stabilize. The framework is also structurally biased toward greenfield or refactoring contexts where teams have the mandate and capacity for the upfront collaborative modeling it demands; in organizations shipping under continuous delivery pressure, the discipline required to maintain bounded contexts and ubiquitous language can feel like an overhead that gets deprioritized exactly when complexity peaks. There is also relatively little guidance on how to handle domains where the business itself does not yet know what it means — a common condition in early-stage product discovery.
Why it matters for product
For a product leader, the bounded context concept is one of the most precise available tools for reasoning about team topology: when two teams use the same word to mean different things — 'user', 'order', 'account' — that semantic gap is usually a signal that the organizational boundary has been drawn wrong or that ownership of a domain is genuinely shared and unresolved. The ubiquitous language argument also reframes roadmap and discovery work: if product, engineering, and the business cannot agree on the vocabulary of a problem, any prioritization built on top of that disagreement will produce a coherent plan and an incoherent system. Evans gives product directors a principled reason to treat language alignment not as a soft cultural nicety but as a structural precondition for delivery.