Anti-Corruption Layer

Protect your domain model by translating at the boundary with systems whose models you don't control.

A translating layer at the boundary keeps a foreign model from leaking into your own.

To an executive

When we depend on an old system or supplier, their way of working can spread into ours. A buffer limits the cost of their changes and eases future replacement.

To an engineer

Put a translation layer between your domain model and the legacy or vendor system. Keep their field names and quirks inside it, so a schema change touches one place.

The idea

In Domain-Driven Design, Eric Evans described the anti-corruption layer as an isolating layer that translates between your model and a foreign one, typically a legacy system or an external vendor. Your side talks to the layer in your own terms; the layer talks to the other system in its terms. Without it, foreign concepts, field names and quirks leak into your design.

The layer lets your bounded context keep its own ubiquitous language while still integrating, and it localises the cost of change when the other system changes. It can be a module inside your application or a separate service.

Why it works

Models spread through integration. Every direct call to a foreign API pulls a little of its model into yours. Over time your code starts thinking in the other system's concepts, and you inherit its design problems.

Translation in one place is cheap to change. When the foreign system changes, only the layer changes. Spread across the codebase, the same change touches every caller.

It makes the boundary explicit. Writing a translator forces the team to decide what each foreign concept means in their own domain, which often exposes misunderstandings early.

Where it applies

Legacy migrations, especially strangler-fig migrations where new services must call the old system for years.
Vendor and SaaS integrations, where the vendor's model was designed for many customers, not for you.
Mergers and shared platforms, where two domains with different semantics must exchange data.
Untrusted inputs, where the boundary is also a good place to validate and sanitise.

How to apply

Define your own model first, in your own language, without looking at the foreign schema.
Put all translation in one layer, with facades or adapters that convert requests and responses both ways.
Keep business rules out of it. The layer translates; decisions belong in your domain.
Test the translations with recorded examples from the foreign system, and monitor the layer for failures.
Decide whether it is permanent. In a migration, plan to retire the layer once the legacy system is gone.

Example scenario

A new claims service integrated directly with a mainframe's 400-field record format. Within months, mainframe codes and field names had spread into every module, and each change to the record layout meant edits across the service.

The team introduced a layer that translated the record into a small, clean Claim model and back again. The rest of the service now spoke only in claims terms, the code shrank noticeably, and the next mainframe layout change touched one module and its tests.

Questions to ask

Whose model are we adopting if we integrate with this system directly?
Where exactly does translation between the two models live, and who owns it?
If the external system changes its schema tomorrow, how many of our modules change?

When not to use it

Collaborating contexts you trust, where teams share or negotiate a model and translation adds cost without protection.
Systems with no real semantic difference, where a thin client is enough.
Latency-critical paths, where an extra hop or service matters; keep the layer in-process there.

How it misleads you

Wrapping every internal call in translation. The pattern is for genuinely foreign or untrusted models, not for trusted, collaborating contexts. A second trap is letting the layer grow business logic and orchestration until it becomes a system of its own that nobody owns.