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

AGGREGATE
 roots.
For now there is no 
Handling Event Repository
, because we decided to implement the
association with 
Delivery History
as a collection in the first iteration, and we have no application
requirement to find out what has been loaded onto a 
Carrier Movement
. Either of these reasons
could change; if they did, then we would add a 
REPOSITORY
.

---

[ Team LiB ]

---

[ Team LiB ]
Walking Through Scenarios
To cross-check all these decisions, we have to constantly step through scenarios to confirm that
we can solve application problems effectively.
Sample Application Feature: Changing the Destination of a Cargo
Occasionally a 
Customer
calls up and says, "Oh no! We said to send our cargo to Hackensack, but
we really need it in Hoboken." We are here to serve, so the system is required to provide for this
change.
Delivery Specification
is a 
VALUE OBJECT
, so it would be simplest to just to throw it away and get
a new one, then use a setter method on 
Cargo
to replace the old one with the new one.
Sample Application Feature: Repeat Business
The users say that repeated bookings from the same 
Customers
tend to be similar, so they want
to use old 
Cargoes
as prototypes for new ones. The application will allow them to find a 
Cargo
in
the 
REPOSITORY
and then select a command to create a new 
Cargo
based on the selected one.
We'll design this using the 
PROTOTYPE
pattern (Gamma et al. 1995).
Cargo
is an 
ENTITY
and is the root of an 
AGGREGATE
. Therefore, it must be copied carefully; we
need to consider what should happen to each object or attribute enclosed by its 
AGGREGATE
boundary. Let's go over each one: