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

Sales Management System Interface
to handle the machinery of talking to the other program,
but it wouldn't be responsible for translation. Also, it would be hidden behind the 
Allocation
Checker
, so it wouldn't show up in the domain design.
Enhancing the Model: Segmenting the Business
Now that we have outlined the interaction of the two systems, what kind of interface are we going
to supply that can answer the question "How much of this type of 
Cargo
may be booked?" The
tricky issue is to define what the "type" of a 
Cargo
is, because our domain model does not
categorize 
Cargoes
yet. In the 
Sales Management System
, 
Cargo
types are just a set of
category keywords, and we could conform our types to that list. We could pass in a collection of
strings as an argument. But we would be passing up another opportunity: this time, to reabstract
the domain of the other system. We need to enrich our domain model to accommodate the
knowledge that there are categories of cargo. We should brainstorm with a domain expert to work
out the new concept.
Sometimes (as will be discussed in Chapter 11) an analysis pattern can give us an idea for a
modeling solution. The book 
Analysis Patterns
(Fowler 1996) describes a pattern that addresses
this kind of problem: the 
ENTERPRISE SEGMENT
. An 
ENTERPRISE SEGMENT
is a set of dimensions that
define a way of breaking down a business. These dimensions could include all those mentioned
already for the shipping business, as well as time dimensions, such as month to date. Using this
concept in our model of allocation makes the model more expressive and simplifies the interfaces.
A class called "
Enterprise Segment"
will appear in our domain model and design as an additional
VALUE OBJECT
, which will have to be derived for each