What is an Anti-Corruption Layer?
Learn what an anti-corruption layer is in Domain-Driven Design, how it translates between domain models, and why it protects clean architecture.
Expected Interview Answer
An anti-corruption layer is a translation boundary placed between two systems with different domain models, so that a service’s internal model stays clean and is never distorted by a legacy or external system’s incompatible concepts, formats, or assumptions.
The term comes from Domain-Driven Design: when a new service integrates with a legacy monolith, a third-party API, or another team’s bounded context, calling that external system’s model directly leaks its quirks, naming, and assumptions into the new service, gradually corrupting its otherwise clean domain design. An anti-corruption layer sits at the integration boundary and translates between the two models in both directions, exposing only concepts meaningful to the new service’s own domain and converting them to and from whatever shape the external system expects. This typically takes the form of an adapter, facade, or dedicated translation service containing mapping logic, and it absorbs churn from the external system, so changes to the legacy API only require updating the translation layer rather than rippling through the new service’s core logic. It is a deliberate cost, extra code and a translation hop, paid specifically to protect the integrity of a bounded context’s domain model.
- Keeps the new service’s domain model clean and free of legacy or external system concepts
- Isolates the blast radius of external API changes to a single translation layer
- Enables gradual migration away from a legacy system without permanently coupling to its model
- Makes the new service’s core logic easier to test and reason about, independent of external quirks
AI Mentor Explanation
An anti-corruption layer is like a translator standing between a franchise’s analytics team and an old-school scorer who still records everything in archaic notation instead of letting that notation leak directly into modern spreadsheets. The translator converts every quirky old scoring symbol into clean, standardized stats before the analytics team ever sees it, so the team’s models are never built around the scorer’s idiosyncrasies. If the old scorer changes their shorthand, only the translator’s mapping needs updating, not the analytics team’s entire system. That deliberate translation boundary protecting a clean model from a messy external one is exactly what an anti-corruption layer provides.
Step-by-Step Explanation
Step 1
Identify the model mismatch
Recognize that the external or legacy system’s domain model differs meaningfully from the new service’s own bounded context.
Step 2
Introduce a translation boundary
Build an adapter, facade, or dedicated service that sits between the two systems at the integration point.
Step 3
Map in both directions
The layer converts external requests/responses into the new service’s clean domain model, and vice versa, absorbing all quirks.
Step 4
Contain future churn
When the external system changes, only the translation layer’s mapping logic is updated; the core domain model stays untouched.
What Interviewer Expects
- Grounds the answer in Domain-Driven Design and bounded contexts
- Explains that the layer translates in both directions to protect the internal model
- Distinguishes it from a simple adapter by emphasizing the deliberate protection-of-domain-integrity intent
- Mentions concrete forms: adapter, facade, or dedicated translation/integration service
Common Mistakes
- Describing it as just “an API wrapper” without mentioning domain model protection
- Confusing it with the adapter pattern in general without the DDD bounded-context framing
- Forgetting that translation happens in both directions, not just incoming data
- Underestimating the ongoing maintenance cost of keeping the translation layer in sync with external changes
Best Answer (HR Friendly)
“An anti-corruption layer is a translation layer you put between your service and some other system, like an old legacy application or a third-party API, so that the other system’s messy or outdated way of modeling things never leaks into your own clean codebase. You do the translation work in one place, so if the other system changes, you only have to update that one boundary instead of code scattered throughout your service.”
Code Example
// Clean internal domain model used everywhere in our service
function toDomainOrder(legacyOrder) {
return {
orderId: legacyOrder.ORD_ID,
customerId: legacyOrder.CUST_REF,
total: parseFloat(legacyOrder.AMT_TOTAL_CENTS) / 100,
status: mapLegacyStatus(legacyOrder.STAT_CD),
}
}
function mapLegacyStatus(code) {
const map = { P: "pending", S: "shipped", C: "cancelled" }
return map[code] || "unknown"
}
// Our domain logic never sees ORD_ID, CUST_REF, STAT_CD, etc.
async function fetchOrder(orderId) {
const legacyOrder = await legacyApiClient.getOrder(orderId)
return toDomainOrder(legacyOrder) // translated at the boundary
}Follow-up Questions
- How does an anti-corruption layer relate to bounded contexts in Domain-Driven Design?
- When is the cost of building an anti-corruption layer not worth it?
- How would you test an anti-corruption layer’s translation logic in isolation?
- How does an anti-corruption layer help during a strangler fig migration away from a legacy system?
MCQ Practice
1. What is the primary purpose of an anti-corruption layer?
An anti-corruption layer isolates a service’s clean domain model from a legacy or external system’s incompatible model by translating at the boundary.
2. Which design discipline is the anti-corruption layer concept drawn from?
The anti-corruption layer is a Domain-Driven Design pattern used to protect a bounded context’s model from external systems.
3. What happens when the external legacy system changes its API or data format?
Because the translation logic is isolated in the anti-corruption layer, external changes are absorbed there without rippling into the core domain model.
Flash Cards
What is an anti-corruption layer? — A translation boundary that protects a service’s clean domain model from a legacy or external system’s incompatible model.
Which methodology introduced the term? — Domain-Driven Design (DDD), in the context of bounded contexts.
What forms can it take? — An adapter, a facade, or a dedicated translation/integration service.
Key benefit when the external system changes? — Only the translation layer needs updating, not the internal domain logic.