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

CORE DOMAIN
 harder to discern
and understand. The model clogs up with general principles everyone knows or details
that belong to specialties which are not your primary focus but play a supporting role.
Yet, however generic, these other elements are essential to the functioning of the
system and the full expression of the model.
There is a part of your model that you would like to take for granted. It is undeniably part of the
domain model, but it abstracts concepts that would probably be needed for a great many
businesses. For example, a corporate organization chart is needed in some form by businesses as
diverse as shipping, banking, or manufacturing. For another example, many applications track
receivables, expense ledgers, and other financial matters that could all be handled using a generic
accounting model.
Often a great deal of effort is spent on peripheral issues in the domain. I personally have
witnessed two separate projects that have employed their best developers for weeks in
redesigning dates and times with time zones. While such components must work, they are not the
conceptual core of the system.
Even if such a generic model element is deemed critical, the overall domain model needs to make
prominent the most valueadding and special aspects of your system, and needs to be structured to
give that part as much power as possible. This is hard to do when the 
CORE
is mixed with all the
interrelated factors.
Therefore:
Identify cohesive subdomains that are not the motivation for your project. Factor out
generic models of these subdomains and place them in separate 
MODULES
. Leave no
trace of your specialties in them.
Once they have been separated, give their continuing development lower priority than
the 
CORE DOMAIN