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

Segregated Core
Elements in the model may partially serve the 
CORE DOMAIN
 and partially play
supporting roles. 
CORE
 elements may be tightly coupled to generic ones. The conceptual
cohesion of the 
CORE
 may not be strong or visible. All this clutter and entanglement
chokes the 
CORE
. Designers can't clearly see the most important relationships, leading
to a weak design.
By factoring out 
GENERIC SUBDOMAINS
, you clear away some of the obscuring detail from the
domain, making the 
CORE
more visible. But it is hard work identifying and clarifying all these
subdomains, and some of them don't seem worth the trouble. Meanwhile, the all-important 
CORE
DOMAIN
is left entangled with the residue.
Therefore:
Refactor the model to separate the 
CORE
 concepts from supporting players (including
ill-defined ones) and strengthen the cohesion of the 
CORE
 while reducing its coupling to
other code. Factor all generic or supporting elements into other objects and place them
into other packages, even if this means refactoring the model in ways that separate
highly coupled elements.
This is basically taking the same principles we applied to 
GENERIC SUBDOMAINS
but from the other
direction. The cohesive subdomains that are central to our application can be identified and
partitioned into coherent packages of their own. What is done with the undifferentiated mass left
behind is important, but not as important. It can be left more or less where it was, or placed into
packages based on prominent classes. Eventually, more and more of the residue can be factored
into 
GENERIC SUBDOMAINS
, but in the short term any easy solution will do, just so the focus on the
SEGREGATED CORE
is retained.
The steps needed to refactor to 
SEGREGATED CORE
are typically something like these:
Identify a 
CORE
subdomain (possibly drawing from the distillation document).