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

Customer
seems to belong in the 
CORE
. Yet the interactions during
delivery do not usually need to involve the 
Customer
class now that the 
Customer Agreement
is available directly. And the basic model of a 
Customer
is pretty generic.
A strong argument could be made for 
Leg
to remain in the 
CORE
. I tend to be minimalist in the
CORE
, and the 
Leg
has tighter cohesion with 
Transport Schedule, Routing Service
, and
Location
, none of which needed to be in the 
CORE
. But if a lot of the stories I wanted to tell about
this model involved 
Legs
, I'd move it into the 
Delivery 
package and suffer the awkwardness of its
separation from those other classes.
In this example, all the class definitions are the same as before, but often distillation requires
refactoring the classes themselves to separate the generic and domain-specific responsibilities,
which can then be segregated.
Now that we have a 
SEGREGATED CORE
, the refactoring is complete. But the 
Shipping
package we
are left with is just "everything left over after we pulled out the 
CORE
." We can follow up with other
refactorings to get more communicative packaging, as shown in Figure 15.4.
Figure 15.4. Meaningful 
MODULES
 for non-
CORE
 subdomains follow after
the 
SEGREGATED CORE
 is complete.

---

It might take several refactorings to get to this point; it doesn't have to be done all at once. Here,
we've ended up with one 
SEGREGATED CORE
package, one 
GENERIC SUBDOMAIN
, and two domain-
specific packages in supporting roles. Deeper insight might eventually produce a 
GENERIC
SUBDOMAIN
for 
Customer
, or it might end up more specialized for shipping.
Recognizing useful, meaningful 
MODULES
is a modeling activity (as discussed in Chapter 5).
Developers and domain experts collaborate in strategic distillation as part of the knowledge
crunching process.
[ Team LiB ]

---

[ Team LiB ]
Abstract Core
Even the 
CORE DOMAIN
model usually has so much detail that communicating the big picture can be
difficult.
We usually deal with a large model by breaking it into narrower subdomains that are small enough
to be grasped and placing them in separate 
MODULES
. This reductive style of packaging often works
to make a complicated model manageable. But sometimes creating separate 
MODULES
can obscure
or even complicate the interactions between the subdomains.