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

Example
Hearing a Missing Concept in the Shipping Model
The team had already developed a working application that could book a cargo. They were starting
to build an "operations support" application that would help juggle the work orders for loading and
unloading cargos at the origin and destination and at transfers between ships.

---

The booking application used a routing engine to plan the trip for a cargo. Each leg of the journey
was stored in a row of a database table, indicating the ID of the vessel voyage (a particular
voyage by a particular ship) slated to carry the cargo, the location where it would be loaded, and
the location where it would be unloaded.
Figure 9.1.
Let's eavesdrop on a conversation (heavily abbreviated) between the developer and a shipping
expert.
Developer:
I want to make sure the "cargo bookings" table has all the data that the operations
application will need.
Expert:
They're going to need the whole itinerary for the 
Cargo
. What information does it have
now?
Developer:
The cargo ID, the vessel voyage, the loading port, and the unloading port for each
leg.
Expert:
What about the date? Operations will need to contract handling work based on the
expected times.
Developer:
Well, that can be derived from the schedule of the vessel voyage. The table data is
normalized.
Expert:
Yes, it is normal to need the date. Operations people use these kinds of itineraries to plan
for upcoming handling work.
Developer:
Yeah . . . OK, they'll definitely have access to the dates. The operations management
application will be able to provide the whole loading and unloading sequence, with the date of each
handling operation. The "itinerary," I guess you would say.
Expert:
Good. The itinerary is the main thing they'll need. Actually, you know, the booking
application has a menu item that will print an itinerary or e-mail it to the customer. Can you use
that somehow?

---