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

of contention with the Cargo 
AGGREGATE
.

---

This leaves the 
Delivery History
with no persistent state. At this point, there is no real need to
keep it around. We could derive 
Delivery History
itself whenever it is needed to answer some
question. We can derive this object because, although the 
ENTITY
will be repeatedly recreated, the
association with the same 
Cargo
object maintains the thread of continuity between incarnations.
The circular reference is no longer tricky to create and maintain. The 
Cargo Factory
will be
simplified to no longer attach an empty 
Delivery History
to new instances. Database space can
be reduced slightly, and the actual number of persistent objects might be reduced considerably,
which is a limited resource in some object databases. If the common usage pattern is that the user
seldom queries for the status of a 
Cargo
until it arrives, then a lot of unneeded work will be
avoided altogether.
On the other hand, if we are using an object database, traversing an association or an explicit
collection is probably much faster than a 
REPOSITORY
query. If the access pattern includes frequent
listing of the full history, rather than the occasional targeted query of last position, the
performance trade-off might favor the explicit collection. And remember that the added feature
("What is on this 
Carrier Movement
?") hasn't been requested yet, and may never be, so we
don't want to pay much for that option.
These kinds of alternatives and design trade-offs are everywhere, and I could come up with lots of
examples just in this little simplified system. But the important point is that these are degrees of
freedom within the same model. By modeling 
VALUES
, 
ENTITIES
, and their 
AGGREGATES
as we have,
we have reduced the impact of such design changes. For example, in this case all changes are
encapsulated within the