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

Cargo
that owns it. This will become clearer
when we model the 
AGGREGATES
.
Delivery Specification
Although it represents the goal of a 
Cargo
, this abstraction does not depend on 
Cargo
. It really
expresses a hypothetical state of some 
Delivery History
. We hope that the 
Delivery History
attached to our 
Cargo
will eventually satisfy the 
Delivery Specification
attached to our 
Cargo
.
If we had two 
Cargoes
going to the same place, they could share the same 
Delivery
Specification
, but they could not share the same 
Delivery History
, even though the histories
start out the same (empty). 
Delivery Specifications
are 
VALUE OBJECTS
.
Role and Other Attributes
Role says something about the association it qualifies, but it has no history or continuity. It is a
VALUE OBJECT
, and it could be shared among different 
Cargo
/
Customer
associations.
Other attributes such as time stamps or names are 
VALUE OBJECTS
.
[ Team LiB ]

---

[ Team LiB ]
Designing Associations in the Shipping Domain
None of the associations in the original diagram specified a traversal direction, but bidirectional
associations are problematic in a design. Also, traversal direction often captures insight into the
domain, deepening the model itself.
If the 
Customer
has a direct reference to every 
Cargo
it has shipped, it will become cumbersome
for long-term, repeat 
Customers
. Also, the concept of a 
Customer
is not specific to