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

Cargo
to 
Delivery
History
to 
History Event
and back to 
Cargo
, complicates instance creation. The 
Delivery
History
holds a collection of 
Handling Events
relevant to its 
Cargo
, and the new object must be
added to this collection as part of the transaction. If this back-pointer were not created, the
objects would be inconsistent.
Figure 7.5. Adding a Handling Event requires inserting it into a Delivery
History.

---

Creation of the back-pointer could be encapsulated in the 
FACTORY
(and kept in the domain layer
where it belongs), but now we'll look at an alternative design that eliminates this awkward
interaction altogether.
[ Team LiB ]

---

[ Team LiB ]
Pause for Refactoring: An Alternative Design of the
Cargo A
GGREGATE
Modeling and design is not a constant forward process. It will grind to a halt unless there is
frequent refactoring to take advantage of new insights to improve the model and the design.
By now, there are a couple of cumbersome aspects to this design, although it does work and it
does reflect the model. Problems that didn't seem important when starting the design are
beginning to be annoying. Let's go back to one of them and, with the benefit of hindsight, stack
the design deck in our favor.
The need to update 
Delivery History
when adding a 
Handling Event
gets the 
Cargo
AGGREGATE
involved in the transaction. If some other user was modifying 
Cargo
at the same time, the
Handling Event
transaction could fail or be delayed. Entering a 
Handling Event
is an
operational activity that needs to be quick and simple, so an important application requirement is
the ability to enter