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

Sales Management System 
into our
booking system cleanly, enriching the domain.
A final design question: Why not give 
Cargo
the responsibility of deriving the 
Enterprise
Segment
? At first glance it seems elegant, if all the data the derivation is based on is in the
Cargo
, to make it a derived attribute of 
Cargo
. Unfortunately, it is not that simple. 
Enterprise
Segments
are defined arbitrarily to divide along lines useful for business strategy. The same
ENTITIES
could be segmented differently for different purposes. We are deriving the segment for a
particular 
Cargo
for 
booking allocation
purposes, but it could have a completely different
Enterprise Segment
for tax accounting purposes. Even the allocation 
Enterprise Segment
could change if the 
Sales Management System
is reconfigured because of a new sales strategy.
So the 
Cargo 
would have to know about the 
Allocation Checker
, which is well outside its
conceptual responsibility, and it would be laden with methods for deriving specific types of
Enterprise Segment
. Therefore, the responsibility for deriving this value lies properly with the
object that knows the rules for segmentation, rather than the object that has the data to which
those rules apply. Those rules could be split out into a separate "
Strategy
" object, which could be
passed to a 
Cargo
to allow it to derive an 
Enterprise Segment
. That solution seems to go
beyond the requirements we have here, but it would be an option for a later design and shouldn't
be a very disruptive change.
[ Team LiB ]

---

[ Team LiB ]