Domain-Driven Design: Tackling Complexity in the Heart of Software

part and redesigning the other modules that use it.
The second, and more important, reason is that those industry-specific concepts belong either in
the 
CORE DOMAIN
or in their own, more specialized, subdomains, and those specialized models are
even more valuable than the generic ones.
Project Risk Management
Agile processes typically call for managing risk by tackling the riskiest tasks early. XP specifically
calls for getting an end-to-end system up and running immediately. This initial system often
proves a technical architecture, and it is tempting to build a peripheral system that handles some
supporting 
GENERIC SUBDOMAIN
because these are usually easier to analyze. But be careful; this
can defeat the purpose of risk management.
Projects face risk from both sides, with some projects having greater technical risks and others
greater domain modeling risks. The end-to-end system mitigates risk only to the extent that it is
an embryonic version of the challenging parts of the actual system. It is easy to underestimate the
domain modeling risk. It can take the form of unforeseen complexity, inadequate access to
business experts, or gaps in key skills of the developers.
Therefore, except when the team has proven skills and the domain is very familiar, the first-cut
system should be based on some part of the 
CORE DOMAIN
, however simple.
The same principle applies to any process that tries to push high-risk tasks forward: the 
CORE
DOMAIN
is high risk because it is often unexpectedly difficult and because without it, the project

---

cannot succeed.
Most of the distillation patterns in this chapter show how to change the model and code to distill
the 
CORE DOMAIN
. However, the next two patterns, 
DOMAIN VISION STATEMENT
and 
HIGHLIGHTED
CORE
, show how the use of supplemental documents can, with a very minor investment, improve
communication and awareness of the 
CORE
and focus development effort. . . .
[ Team LiB ]

---

[ Team LiB ]