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

Figure 7.8. M
ODULES
 based on broad domain concepts

---

The 
MODULE
names in Figure 7.8 contribute to the team's language. Our company does 
shipping
for 
customers
so that we can 
bill 
them. Our sales and marketing people deal with 
customers
, and
make agreements with them. The operations people do the 
shipping
, getting the cargo to its
specified destination. The back office takes care of 
billing
, submitting invoices according to the
pricing in the 
customer's 
agreement. That's one story I can tell with this set of 
MODULES
.
This intuitive breakdown could be refined, certainly, in successive iterations, or even replaced
entirely, but it is now aiding 
MODEL-DRIVEN DESIGN
and contributing to the 
UBIQUITOUS LANGUAGE
.
[ Team LiB ]

---

[ Team LiB ]
Introducing a New Feature: Allocation Checking
Up to this point, we've been working off the initial requirements and model. Now the first major
new functions are going to be added.
The sales division of the imaginary shipping company uses other software to manage client
relationships, sales projections, and so forth. One feature supports yield management by allowing
the firm to allocate how much cargo of specific types they will attempt to book based on the type
of goods, the origin and destination, or any other factor they may choose that can be entered as a
category name. These constitute goals of how much will be sold of each type, so that more
profitable types of business will not be crowded out by less profitable cargoes, while at the same
time avoiding underbooking (not fully utilizing their shipping capacity) or excessive overbooking
(resulting in bumping cargo so often that it hurts customer relationships).
Now they want this feature to be integrated with the booking system. When a booking comes in,
they want it checked against these allocations to see if it should be accepted.
The information needed resides in two places, which will have to be queried by the