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

Cargo
Two identical crates must be distinguishable, so 
Cargo
objects are 
ENTITIES
. In practice, all
shipping companies assign tracking IDs to each piece of cargo. This ID will be automatically
generated, visible to the user, and in this case, probably conveyed to the customer at booking
time.
Handling Event and Carrier Movement
We care about such individual incidents because they allow us to keep track of what is going on.
They reflect real-world events, which are not usually interchangeable, so they are 
ENTITIES
. Each
Carrier Movement
will be identified by a code obtained from a shipping schedule.
Another discussion with a domain expert reveals that 
Handling Events
can be uniquely identified
by the combination of 
Cargo
ID, completion time, and type. For example, the same 
Cargo
cannot
be both loaded and unloaded at the same time.
Location
Two places with the same name are not the same. Latitude and longitude could provide a unique
key, but probably not a very practical one, since those measurements are not of interest to most
purposes of this system, and they would be fairly complicated. More likely, the 
Location
will be
part of a geographical model of some kind that will relate places according to shipping lanes and
other domain-specific concerns. So an arbitrary, internal, automatically generated identifier will
suffice.

---

Delivery History
This is a tricky one. 
Delivery Histories
are not interchangeable, so they are 
ENTITIES
. But a
Delivery History
has a one-to-one relationship with its 
Cargo
, so it doesn't really have an
identity of its own. Its identity is borrowed from the