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

Booking
Application
so that it can either accept or reject the requested booking. A sketch of the general
information flows looks something like this.
Figure 7.9. Our Booking Application must use information from the
Sales Management System and from our own domain 
REPOSITORIES
.
Connecting the Two Systems
The 
Sales Management System
was not written with the same model in mind that we are
working with here. If the 
Booking Application 
interacts with it directly, our application will have
to accommodate the other system's design, which will make it harder to keep a clear 
MODEL-
DRIVEN DESIGN
and will confuse the 
UBIQUITOUS LANGUAGE
. Instead, let's create another class whose
job it will be to translate between our model and the language of the 
Sales Management
System
. It will not be a general translation mechanism. It will expose just the features our
application needs, and it will reabstract them in terms of our domain model. This class will act as
an 
ANTICORRUPTION LAYER
(discussed in Chapter 14).
This is an interface to the 
Sales Management System
, so we might first think of calling it
something like "
Sales Management Interface
." But we would be missing an opportunity to use

---

language to recast the problem along lines more useful to us. Instead, let's define a 
SERVICE
for
each of the allocation functions we need to get from the other system. We'll implement the
SERVICES
with a class whose name reflects its responsibility in our system: "
Allocation Checker
."
If some other integration is needed (for example, using the 
Sales Management System's
customer database instead of our own 
Customer
REPOSITORY
), another translator can be created
with 
SERVICES
fulfilling that responsibility. It might still be useful to have a lower level class like