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

Isolating the Domain: Introducing the Applications
To prevent domain responsibilities from being mixed with those of other parts of the system, let's
apply 
LAYERED ARCHITECTURE
to mark off a domain layer.
Without going into deep analysis, we can identify three user-level application functions, which we
can assign to three application layer classes.
A 
Cargo_1._A_Booking_Application'>Tracking Query
that can access past and present handling of a particular 
Cargo
1.
A 
Booking Application
that allows a new 
Cargo
to be registered and prepares the system
for it
2.
An 
Incident Logging Application
that can record each handling of the 
Cargo
(providing
the information that is found by the 
Tracking Query
)
3.
These application classes are coordinators. They should not work out the answers to the questions
they ask. That is the domain layer's job.
[ Team LiB ]

---

[ Team LiB ]
Distinguishing E
NTITIES
 and V
ALUE
 Objects
Considering each object in turn, we'll look for identity that must be tracked or a basic value that is
represented. First we'll go through the clear-cut cases and then consider the more ambiguous
ones.
Customer
Let's start with an easy one. A 
Customer
object represents a person or a company, an entity in
the usual sense of the word. The 
Customer
object clearly has identity that matters to the user, so
it is an 
ENTITY
in the model. How to track it? Tax ID might be appropriate in some cases, but an
international company could not use that. This question calls for consultation with a domain
expert. We discuss the problem with a businessperson in the shipping company, and we discover
that the company already has a customer database in which each 
Customer
is assigned an ID
number at first sales contact. This ID is already used throughout the company; using the number
in our software will establish continuity of identity between those systems. It will initially be a
manual entry.