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

Look at the conceptual dependencies in your model and the varying rates and sources
of change of different parts of your domain. If you identify natural strata in the domain,
cast them as broad abstract responsibilities. These responsibilities should tell a story of
the high-level purpose and design of your system. Refactor the model so that the
responsibilities of each domain object, 
AGGREGATE
, and 
MODULE
 fit neatly within the
responsibility of one layer.
This is a pretty abstract description, but it will become clear with a few examples. The satellite
communications simulator whose story opened this chapter layered its responsibility. I have seen
RESPONSIBILITY LAYERS
used to good effect in domains as various as manufacturing control and
financial management.
The following example explores 
RESPONSIBILITY LAYERS
in detail to give a feel for the discovery of a
large-scale structure of 
any
sort, and the way it guides and constrains modeling and design.

---

Example
In Depth: Layering a Shipping System
Let's look at the implications of applying 
RESPONSIBILITY LAYERS
to the cargo shipping application
discussed in the examples of previous chapters.
As we rejoin the story, the team has made considerable progress creating a 
MODEL-DRIVEN DESIGN
and distilling a 
CORE DOMAIN
. But as the design fleshes out, they are having trouble coordinating
how all the parts fit together. They are looking for a large-scale structure that can bring out the
main themes of their system and keep everyone on the same page.
Here is a look at a representative part of the model.
Figure 16.3. A basic shipping domain model for routing cargoes