Anti-Corruption Layer

When you integrate with a system you don’t control (a third-party API, a legacy system, another team’s context), its model is rarely the one you want. An anti-corruption layer sits between the two and translates, so their changes and quirks stop at the boundary.

What it translates

• Data: their fields and formats into your types.
• Behaviour: their states, errors and edge cases into your domain’s states and errors.
• Vocabulary: your code keeps speaking your own language (Ubiquitous Language for Platforms), not theirs.

Shape

One adapter per upstream, each exposing your interface. Contract tests on both sides of it, and per-integration observability (latency, error rate, rate-limit hits), because third parties change under you and you want to find out before your users do (Contract-Driven Development).

A typical example: connecting several trading venues into one platform. Each venue has its own authentication, rate limits, streaming vs request/response APIs, number precision and order states. An adapter per venue translates all of that into one consistent model of orders, fills and balances, so the rest of the platform, and its users, see a single interface.

The front-end cousin

Modelling API responses in your own types, so the UI depends on your shape rather than the backend’s, is the same move at the edge of a front end (API Modelling).

When it’s not worth it

It’s another layer to maintain. Use it where the upstream is genuinely foreign or volatile, not between two contexts you own that already share a language.