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

Chapter Seven. Using the Language: An
Extended Example
The preceding three chapters introduced a pattern language for honing the fine detail of a model
and maintaining a tight 
MODEL-DRIVEN DESIGN
. In the earlier examples, the patterns were mostly
applied one at a time, but on a real project you have to combine them. This chapter presents one
elaborate example (still drastically simpler than a real project, of course). The example will step
through a succession of model and design refinements as a hypothetical team deals with
requirements and implementation issues and develops a 
MODEL-DRIVEN DESIGN
, showing the forces
that apply and how the patterns of Part II can resolve them.
[ Team LiB ]

---

[ Team LiB ]
Introducing the Cargo Shipping System
We're developing new software for a cargo shipping company. The initial requirements are three
basic functions.
Track key handling of customer cargo
1.
Book cargo in advance
2.
Send invoices to customers automatically when the cargo reaches some point in its handling
3.
In a real project, it would take some time and iteration to get to the clarity of this model. Part III
of this book will go into the discovery process in depth. But here we'll start with a model that has
the needed concepts in a reasonable form, and we'll focus on fine-tuning the details to support
design.
Figure 7.1. A class diagram representing a model of the shipping
domain
This model organizes domain knowledge and provides a language for the team. We can make
statements like this:
"Multiple 
Customers
are involved with a 
Cargo
, each playing a different 
role
."

---

"The