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

Flag the elements of the 
CORE DOMAIN
 within the primary repository of the model,
without particularly trying to elucidate its role. Make it effortless for a developer to
know what is in or out of the 
CORE
.
The 
CORE DOMAIN
is now clearly visible to those working with the model, with a fairly small effort
and low maintenance, at least to the extent that the model is factored fine enough to distinguish
the contributions of parts.
The Distillation Document as Process Tool
Theoretically on an XP project, any pair (two programmers working together) can change any code
in the system. In practice, some changes have major implications, and call for more consultation
and coordination. When working in the infrastructure layer, the impact of a change may be clear,
but it may not be so obvious in the domain layer, as typically organized.
With the concept of the 
CORE DOMAIN
, this impact can be made clear. Changes to the model of the
CORE DOMAIN
should have a big effect. Changes to widely used generic elements may require a lot
of code updating, but they still shouldn't create the conceptual shift that 
CORE
changes do.
Use the distillation document as a guide. When developers realize that the distillation document
itself requires change to stay in sync with their code or model change, then consultation is called
for. Either they are fundamentally changing the 
CORE DOMAIN
elements or relationships, or they are
changing the boundaries of the 
CORE
, including or excluding something different. Dissemination of
the model change to the whole team is necessary by whatever communication channels the team
uses, including distribution of a new version of the distillation document.
If the distillation document outlines the essentials of the