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

Cargo
delivery 
goal
is 
specified
."
"A series of 
Carrier Movements
satisfying the 
Specification
will fulfill the delivery 
goal
."
Each object in the model has a clear meaning:
A 
Handling Event
is a discrete action taken with the 
Cargo
, such as loading it onto a ship or
clearing it through customs. This class would probably be elaborated into a hierarchy of different
kinds of incidents, such as loading, unloading, or being claimed by the receiver.
Delivery Specification
defines a delivery goal, which at minimum would include a destination
and an arrival date, but it can be more complex. This class follows the 
SPECIFICATION
pattern (see
Chapter 9).
This responsibility could have been taken on by the 
Cargo
object, but the abstraction of 
Delivery
Specification
gives at least three advantages.
Without 
Delivery Specification
, the 
Cargo
object would be responsible for the detailed
meaning of all those attributes and associations for specifying the delivery goal. This would
clutter up 
Cargo
and make it harder to understand or change.
1.
This abstraction makes it easy and safe to suppress detail when explaining the model as a
whole. For example, there could be other criteria encapsulated in the 
Delivery
Specification
, but a diagram at this level of detail would not have to expose it. The diagram
is telling the reader that there is a 
SPECIFICATION
of delivery, and the details of that are not
important to think about (and, in fact, could be easily changed later).
2.
This model is more expressive. Adding 
Delivery Specification 
says explicitly that the exact
means of delivery of the