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

Even though team members may know broadly what constitutes the 
CORE DOMAIN
,
different people won't pick out quite the same elements, and even the same person
won't be consistent from one day to the next. The mental labor of constantly filtering
the model to identify the key parts absorbs concentration better spent on design
thinking, and it requires comprehensive knowledge of the model. The 
CORE DOMAIN
 must
be made easier to see.
Significant structural changes to the code are the ideal way of identifying the 
CORE
DOMAIN
, but they are not always practical in the short term. In fact, such major code
changes are difficult to undertake without the very view the team is lacking.
Structural changes in the organization of the model, such as partitioning 
GENERIC SUBDOMAINS
and
a few others to come later in this chapter, can allow the 
MODULES
to tell the story. But as the only
means of communicating the 
CORE DOMAIN
, this is too ambitious to shoot for straight away.
You will probably need a lighter solution to supplement these aggressive techniques. You may
have constraints that prevent you from physically separating the 
CORE
. Or you may be starting out
with existing code that does not differentiate the 
CORE
well, but you really need to see the 
CORE
,
and share that view, to effectively refactor toward better distillation. And even at an advanced
stage, a few carefully selected diagrams or documents provide mental anchor points and entry
points for the team.
These issues arise equally for projects that use elaborate UML models and those (such as XP
projects) that keep few external documents and use the code as the primary repository of the
model. An Extreme Programming team might be more minimalist, keeping these supplements
more casual and more transient (for example, a hand-drawn diagram on the wall for all to see),
but these techniques can fold nicely into the process.
Marking off a privileged part of a model, along with the implementation that embodies it, is a
reflection on the model, not necessarily part of the model itself. Any technique that makes it easy
for everyone to know the 
CORE DOMAIN
will do. Two specific techniques can represent this class of
solutions.