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

Figure 16.4. Using the model to route a cargo during booking
The team members have been steeped in the domain of shipping for months, and they have
noticed some natural stratification of its concepts. It is quite reasonable to discuss transport
schedules (the scheduled voyages of ships and trains) without referring to the cargoes aboard
those transports. It is harder to talk about tracking a cargo without referring to the transport
carrying it. The conceptual dependencies are pretty clear. The team can readily distinguish two
layers: "Operations" and the substrate of those operations, which they dub "Capability."

---

"Operational" Responsibilities
Activities of the company, past, current, and planned, are collected into the Operations layer. The
most obvious Operations object is 
Cargo
, which is the focus of most of the day-to-day activity of
the company. The 
Route Specification
is an integral part of 
Cargo
, indicating delivery
requirements. The 
Itinerary
is the operational delivery plan. Both of these objects are part of the
Cargo's
AGGREGATE
, and their life cycles are tied to the time frame of an active delivery.
"Capability" Responsibilities
This layer reflects the resources the company draws upon in order to carry out operations. The
Transit Leg
is a classic example. The ships are scheduled to run and have a certain capacity to
carry cargo, which may or may not be fully utilized.
True, if we were focused on operating a shipping fleet, 
Transit Leg
would be in the Operations
layer. But the users of this system aren't worried about that problem. (If the company were
involved in both those activities and wanted the two coordinated, the development team might
have to consider a different layering scheme, perhaps with two distinct layers, such as "Transport
Operations" and "Cargo Operations.")
A trickier decision is where to place 
Customer
. In some businesses, customers tend to be
transient: they're interesting while a package is being delivered and then mostly forgotten until
next time. This quality would make customers only an operational concern for a parcel delivery
service aimed at individual consumers. But our hypothetical shipping company tends to cultivate
long-term relationships with customers, and most work comes from repeat business. 
Given these
intentions of the business users
, the 
Customer
belongs in the potential layer. As you can see, 
this
was not a technical decision
. It was an attempt to capture and communicate knowledge of the
domain.
Because the association between