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

Boil the model down. Find the 
CORE DOMAIN
 and provide a means of easily distinguishing
it from the mass of supporting model and code. Bring the most valuable and specialized
concepts into sharp relief. Make the 
CORE
 small.
Apply top talent to the 
CORE DOMAIN
, and recruit accordingly. Spend the effort in the
CORE
 to find a deep model and develop a supple design—sufficient to fulfill the vision of
the system. Justify investment in any other part by how it supports the distilled CORE.
Distilling the 
CORE DOMAIN
is not easy, but it does lead to some easy decisions. You'll put a lot of
effort into making your 
CORE
distinctive, while keeping the rest of the design as generic as is
practical. If you need to keep some aspect of your design secret as a competitive advantage, it is
the 
CORE DOMAIN
. There is no need to waste effort concealing the rest. And whenever a choice has
to be made (due to time limitations) between two desirable refactorings, the one that most affects
the 
CORE DOMAIN
should be chosen first.
The patterns in this chapter make the 
CORE DOMAIN
easier to see and use and change.
Choosing the 
CORE
We are looking at those parts of the model particular to representing your business domain and
solving your business problems.

---

The 
CORE DOMAIN
you choose depends on your point of view. For example, many applications need
a generic model of money that could represent various currencies and their exchange rates and
conversions. On the other hand, an application to support currency trading might need a more
elaborate model of money, which would be considered part of the 
CORE
. Even in such a case, there
may be a part of the money model that is very generic. As insight into the domain deepens with
experience, the distillation process can continue by separating the generic money concepts and
retaining only the specialized aspects of the model in the 
CORE DOMAIN
.
In a shipping application, the 
CORE
could be the model of how cargoes are consolidated for
shipping, how liability is transferred when containers change hands, or how a particular container
is routed on various transports to reach its destination. In investment banking, the 
CORE
could
include the models of syndication of assets among assignees and participants.
One application's 
CORE DOMAIN
is another application's generic supporting component. Still,
throughout one project, and usually throughout one company, a consistent 
CORE
can be defined.
Like every other part of the design, the identification of the 
CORE DOMAIN
should evolve through
iterations. The importance of a particular set of relationships might not be apparent at first. The
objects that seem obviously central at first may turn out to have supporting roles.
The discussion in the following sections, particularly 
GENERIC SUBDOMAINS
, will give more guidelines
for these decisions.