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

Handling Event
is the association to a
Carrier Movement
, which some types of 
Handling Events
don't even have. A basic constructor
that creates a valid 
Handling Event
would be:
public HandlingEvent(Cargo c, String eventType, Date timeStamp) {
handled = c;
type = eventType;
completionTime = timeStamp;
}
Nonidentifying attributes of an 
ENTITY
can usually be added later. In this case, all attributes of the
Handling Event
are going to be set in the initial transaction and never altered (except possibly
for correcting a data-entry error), so it could be convenient, and make client code more
expressive, to add a simple 
FACTORY METHOD
to 
Handling Event
for each event type, taking all the
necessary arguments. For example, a "loading event" does involve a 
Carrier Movement
:
public static HandlingEvent newLoading(
Cargo c, CarrierMovement loadedOnto, Date timeStamp) {
HandlingEvent result =
new HandlingEvent(c, LOADING_EVENT, timeStamp);
result.setCarrierMovement(loadedOnto);
return result;
}
The 
Handling Event
in the model is an abstraction that might encapsulate a variety of specialized
Handling Event
classes, ranging from loading and unloading to sealing, storing, and other
activities not related to 
Carriers
. They might be implemented as multiple subclasses or have
complicated initialization—or both. By adding 
FACTORY METHODS
to the base class (
Handling
Event
) for each type, instance creation is abstracted, freeing the client from knowledge of the
implementation. The 
FACTORY
is responsible for knowing what class was to be instantiated and how
it should be initialized.
Unfortunately, the story isn't quite that simple. The cycle of references, from