Anti-Corruption Boundary Translation
An anti-corruption boundary translates between a legacy or external model and your bounded context, so the foreign model concepts never leak into your domain language and you can evolve independently.
Definition
An anti-corruption boundary is a translation layer that converts the data and semantics of an external or legacy system into the language of your bounded context on the way in, and back on the way out, so that your domain model never adopts the foreign concepts and remains free to evolve.
Context and scope
Applied in legacy migration, third-party API integration, and any context where you consume a model you do not control and must not let it shape your domain.
Common misconceptions
- An ACL is just an adapter — an adapter changes interfaces; an ACL changes the conceptual model, preventing semantic leakage, not just signature mismatch
- ACLs are only for legacy — they apply to any external model you consume, including modern SaaS APIs whose vocabulary you do not want in your domain
Anti-patterns
- Passing the external DTO directly into the domain layer, letting the foreign field names and semantics contaminate the ubiquitous language
- Building the ACL so thinly that a new external field appears in the domain without an explicit translation decision
Related concepts
Authoritative source
What it is
An anti-corruption boundary is a translation layer that converts the data and semantics of an external or legacy system into the language of your bounded context on the way in, and back on the way out, so that your domain model never adopts the foreign concepts and remains free to evolve. Applied in legacy migration, third-party API integration, and any context where you consume a model you do not control and must not let it shape your domain. The organizing principle is which decisions are hard to reverse and should be made once, versus which are easy to reverse and should be deferred.
How it works
Boundaries are drawn along axes of change: things that change together are colocated, things that change independently are separated by interfaces whose contracts are explicit and versioned. Dependencies point toward stability — domain logic depends on abstractions, infrastructure depends on domain, never the reverse. The structure makes the system’s intent legible without reading every module.
When to choose and pitfalls
Choose this structure when the system will outlive its first deployment and face requirements you cannot now predict. The pitfall is premature abstraction — adding indirection for a flexibility that never materializes, paying its complexity cost forever. The opposite pitfall is entangling concerns that later need to separate, forcing a rewrite instead of a refactor.