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

1.
Move related classes to a new 
MODULE
, named for the concept that relates them.
2.
Refactor code to sever data and functionality that are not directly expressions of the concept.
Put the removed aspects into (possibly new) classes in other packages. Try to place them
with conceptually related tasks, but don't waste too much time being perfect. Keep focused
on scrubbing the 
CORE
subdomain and making the references from it to other packages
explicit and self-explanatory.
3.
Refactor the newly 
SEGREGATED CORE MODULE
to make its relationships and interactions
simpler and more communicative, and to minimize and clarify its relationships with other
MODULES
. (This becomes an ongoing refactoring objective.)
4.
Repeat with another 
CORE
subdomain until the 
SEGREGATED CORE
is complete.
5.

---

5.
The Costs of Creating a S
EGREGATED
 C
ORE
Segregating the 
CORE
will sometimes make relationships with tightly coupled non-
CORE
classes
more obscure or even more complicated, but that cost is outweighed by the benefit of clarifying
the 
CORE DOMAIN
and making it much easier to work on.
The 
SEGREGATED CORE
will let you enhance the cohesion of that 
CORE DOMAIN
. There are many
meaningful ways of breaking down a model, and sometimes in the creation of a 
SEGREGATED CORE
a
nicely cohesive 
MODULE
may be broken, sacrificing that cohesion for the sake of bringing out the
cohesiveness of the 
CORE DOMAIN
. This is a net gain, because the greatest value-added of
enterprise software comes from the enterprise-specific aspects of the model.
The other cost, of course, is that segregating the 
CORE
is a lot of work. It must be acknowledged
that a decision to go to a 
SEGREGATED CORE
will potentially absorb developers in changes all over
the system.
The time to chop out a 
SEGREGATED CORE
is when you have a large 
BOUNDED CONTEXT
that is critical
to the system, but where the essential part of the model is being obscured by a great deal of
supporting capability.