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

Delivery History:
We should create a new, empty one, because the history of the old one
doesn't apply. This is the usual case with 
ENTITIES
inside the 
AGGREGATE
boundary.
Customer Roles:
We should copy the 
Map
(or other collection) that holds the keyed
references to 
Customers
, including the keys, because they are likely to play the same roles
in the new shipment. But we have to be careful 
not
to copy the 
Customer
objects
themselves. We must end up with references to the same 
Customer
objects as the old
Cargo
object referenced, because they are 
ENTITIES
outside the 
AGGREGATE
boundary.
Tracking ID:
We must provide a new 
Tracking ID
from the same source as we would when
creating a new 
Cargo
from scratch.
Notice that we have copied everything inside the 
Cargo
AGGREGATE
boundary, we have made
some modifications to the copy, but we have 
affected nothing outside the 
AGGREGATE
 boundary
at
all.
[ Team LiB ]

---

[ Team LiB ]
Object Creation
F
ACTORIES
 and Constructors for Cargo
Even if we have a fancy 
FACTORY
for 
Cargo
, or use another 
Cargo
as the 
FACTORY
, as in the
"Repeat Business" scenario, we still have to have a primitive constructor. We would like the
constructor to produce an object that fulfills its invariants or at least, in the case of an 
ENTITY
, has
its identity intact.
Given these decisions, we might create a 
FACTORY
method on 
Cargo
such as this:
public Cargo copyPrototype(String newTrackingID)
Or we might make a method on a standalone 
FACTORY
such as this:
public Cargo newCargo(Cargo prototype, String newTrackingID)
A standalone 
FACTORY
could also encapsulate the process of obtaining a new (automatically
generated) ID for a new 
Cargo
, in which case it would need only one argument:
public Cargo newCargo(Cargo prototype)
The result returned from any of these 
FACTORIES
would be the same: a