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

Anticorruption Layer
New systems almost always have to be integrated with legacy or other systems, which have their
own models. Translation layers can be simple, even elegant, when bridging well-designed 
BOUNDED
CONTEXTS
with cooperative teams. But when the other side of the boundary starts to leak through,
the translation layer may take on a more defensive tone.
When a new system is being built that must have a large interface with another, the
difficulty of relating the two models can eventually overwhelm the intent of the new
model altogether, causing it to be modified to resemble the other system's model, in an
ad hoc fashion. The models of legacy systems are usually weak, and even the exception
that is well developed may not fit the needs of the current project. Yet there may be a
lot of value in the integration, and sometimes it is an absolute requirement.
The answer is not to avoid all integration with other systems. I've been on projects where people
enthusiastically set out to replace all the legacy, but this is just too much to take on at once.
Besides, integrating with existing systems is a valuable form of reuse. On a large project, one
subsystem will often have to interface with several other, independently developed subsystems.
These will reflect the problem domain differently. When systems based on different models are
combined, the need for the new system to adapt to the semantics of the other system can lead to
a corruption of the new system's own model. Even when the other system is well designed, it is
not based on the 
same
model as the client. And often the other system is not well designed.
There are many hurdles in interfacing with an external system. For example, the infrastructure
layer must provide the means to communicate with another system that might be on a different
platform or use different protocols. The data types of the other system must be translated into
those of your system. But often overlooked is the certainty that the other system does not use the
same conceptual domain model.
It seems clear enough that errors will result if you take some data from one system and
misinterpret it in another. You may even corrupt the database. But even so, this problem tends to
sneak up on us because we think that what we are transporting between systems is primitive
data, whose meaning is unambiguous and must be the same on both sides. This assumption is

---

usually wrong. Subtle yet important differences in meaning arise from the way the data are
associated in each system. And even if primitive data elements do have exactly the same
meaning, it is usually a mistake to make the interface to the other system operate at such a low
level. A low-level interface takes away the power of the other system's model to explain the data
and constrain its values and relationships, while saddling the new system with the burden of
interpreting primitive data that is not in terms of its own model.
We need to provide a translation between the parts that adhere to different models, so that the
models are not corrupted with undigested elements of foreign models.
Therefore: