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

A
GGREGATE
 Boundaries
Customer, Location
, and 
Carrier Movement
have their own identities and are shared by many
Cargoes
, so they must be the roots of their own 
AGGREGATES
, which contain their attributes and
possibly other objects below the level of detail of this discussion. 
Cargo
is also an obvious
AGGREGATE
root, but where to draw the boundary takes some thought.
The 
Cargo
AGGREGATE
could sweep in everything that would not exist but for the particular 
Cargo
,
which would include the 
Delivery History
, the 
Delivery Specification
, and the 
Handling
Events
. This fits for 
Delivery History.
No one would look up a 
Delivery History
directly without
wanting the 
Cargo
itself. With no need for direct global access, and with an identity that is really
just derived from the 
Cargo
, the 
Delivery History
fits nicely inside 
Cargo's
boundary, and it
does not need to be a root. The 
Delivery Specification
is a 
VALUE OBJECT
, so there are no
complications from including it in the 
Cargo
AGGREGATE
.
The 
Handling Event
is another matter. Previously we have considered two possible database
queries that would search for these: one, to find the 
Handling Events
for a 
Delivery History
as
a possible alternative to the collection, would be local within the 
Cargo
AGGREGATE
; the other
would be used to find all the operations to load and prepare for a particular 
Carrier Movement
.
In the second case, it seems that the activity of 
handling
the