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

Cargo
.
Figure 7.10. The Allocation Checker acts as an 
ANTICORRUPTION LAYER
presenting a selective interface to the Sales Management System in
terms of our domain model.

---

The 
Allocation Checker
will translate between 
Enterprise Segments
and the category names
of the external system. The 
Cargo Repository
must also provide a query based on the
Enterprise Segment
. In both cases, collaboration with the 
Enterprise Segment
object can be
used to perform the operations without breaching the 
Segment's
encapsulation and complicating
their own implementations. (Notice that the 
Cargo Repository
is answering a query with a count,
rather than a collection of instances.)
There are still a few problems with this design.
We have given the 
Booking Application
the job of applying this rule: "A 
Cargo
is accepted
if the space allocated for its 
Enterprise Segment
is greater than the quantity already
booked plus the size of the new 
Cargo
." Enforcing a business rule is domain responsibility
and shouldn't be performed in the application layer.
1.
It isn't clear how the 
Booking Application
derives the 
Enterprise Segment
.
2.
Both of these responsibilities seem to belong to the 
Allocation Checker
. Changing its interface
can separate these two 
SERVICES
and make the interaction clear and explicit.
Figure 7.11. Domain responsibilities shifted from Booking Application
to Allocation Checker

---

The only serious constraint imposed by this integration will be that the