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

The Distillation Document
Often I create a separate document to describe and explain the 
CORE DOMAIN
. It can be as simple
as a list of the most essential conceptual objects. It can be a set of diagrams focused on those
objects, showing their most critical relationships. It can walk through the fundamental interactions
at an abstract level or by example. It can use UML class or sequence diagrams, nonstandard
diagrams particular to the domain, carefully worded textual explanations, or combinations of
these. 
A distillation document is not a complete design document
. It is a minimalist entry point

---

that delineates and explains the 
CORE
and suggests reasons for closer scrutiny of particular pieces.
The reader is given a broad view of how the pieces fit and guided to the appropriate part of the
code for more details.
Therefore (as one form of 
HIGHLIGHTED CORE
):
Write a very brief document (three to seven sparse pages) that describes the 
CORE
DOMAIN
 and the primary interactions among 
CORE
 elements.
All the usual risks of separate documents apply.
The document may not be maintained.
1.
The document may not be read.
2.
By multiplying the information sources, the document may defeat its own purpose of cutting
through complexity.
3.
The best way to limit these risks is to be absolutely minimalist. Staying away from mundane detail
and focusing on the central abstractions and their interactions allows the document to age more
slowly, because this level of the model is usually more stable.
Write the document to be understood by the nontechnical members of the team. Use it as a
shared view that delineates what every-one needs to know, and a guide by which all team
members may start their exploration of the model and code.