A Billing bounded context needs data from a legacy Inventory system whose data model uses incompatible concepts (e.g., a single 'SKU status' enum that encodes both stock level and discontinuation). What pattern keeps that legacy model from leaking into and corrupting Billing's own domain model, and how does it work mechanically?

## The situation it is named for An **Anti-Corruption Layer (ACL)** is the mechanism DDD names for a specific, common situation: your bounded context needs data or behavior from another system - often a legacy system, a third-party vendor, or another team's poorly modeled context - whose concepts don't map cleanly onto your own domain model, and you need to consume it without importing its conceptual mess into your own code. ## The pieces it is made of Mechanically, an ACL sits as a distinct layer between your domain code and the external system, typically implemented as a combination of: - an **adapter** (or several) that speaks the external system's native protocol - calling its REST API, reading its database, parsing its file format; - a **facade** that presents a single, clean interface to the rest of your domain code; - between those two pieces, **translation logic** that converts the external system's data and concepts into types expressed entirely in your own domain's ubiquitous language. Concretely: if a legacy Inventory system encodes both current stock level and product discontinuation status into one overloaded 'SKU status' enum with values like `ACTIVE_LOW`, `ACTIVE_HIGH`, `DISCONTINUED_WITH_STOCK`, `DISCONTINUED_NO_STOCK`, the ACL's translator reads that raw enum and produces two independent, explicit concepts in Billing's own model - say, a `StockLevel` value object and a separate boolean `isDiscontinued` flag - because that's how Billing's own domain logic actually reasons about the business, and it should never need to understand or pattern-match on Inventory's historically-accumulated encoding scheme. ## Why it exists: protecting model integrity The reason this exists is to protect **model integrity**. Domain models earn their value from being clean, explicit expressions of the business concepts a team's code actually needs to reason about; if you let an external system's accidental complexity, historical quirks, and unrelated concerns leak directly into your model - by, say, mapping fields 1:1 with matching names and matching enum values - your own domain code inherits every ambiguity, workaround, and legacy assumption baked into the other system, and you lose the very benefit a well-modeled bounded context was supposed to provide. The ACL is the place where that translation and simplification happens explicitly and visibly, rather than being smeared invisibly throughout your business logic. ## What it costs and what it buys The trade-off cuts both ways. | Side of the ledger | What it means | |---|---| | **On the cost side** | an ACL is real code to write, test, and maintain - translator functions, adapters, and often a set of tests specifically asserting the mapping behaves correctly under the external system's various quirks and edge cases - plus, if implemented as a network-calling layer, a potential latency or availability overhead versus calling the external system directly | | **On the benefit side** | your domain model stays pure and independent of the external system's churn - if Inventory's team changes their enum values, or your company swaps the legacy Inventory system for a different vendor entirely, only the ACL's translation code needs to change; Billing's domain logic, business rules, and tests remain untouched, because they were never written in terms of Inventory's representation in the first place | ## The failure mode: decay into a passthrough The clearest production failure mode is **ACL decay into a thin passthrough**. Over time, under delivery pressure: 1. a translator that started as genuine conceptual translation gets replaced field-by-field with near-identical renames that mirror the upstream shape exactly; 2. upstream-specific concepts (like the overloaded status enum) start appearing directly inside downstream business logic or tests 'just this once'; 3. eventually every upstream schema change once again ripples deep into the downstream domain model - at which point the ACL exists in name only and provides none of its intended protection. Detecting this requires periodically checking whether the downstream model's types and vocabulary still read as native to the downstream domain, or have started to mirror the upstream system's naming and structure. ## When not to build one It's also worth knowing when not to build one: if the upstream system's model is already clean, stable, and conceptually well-aligned with your own domain - most commonly when integrating with a trusted internal team's well-designed **Open Host Service** - the translation overhead of a full ACL may not earn its cost, and the **Conformist** pattern (adopting the upstream model as-is) can be the more pragmatic choice. The decision to build an ACL, then, is really a judgment call about how much you distrust or diverge from the upstream model, weighed against the ongoing cost of maintaining the translation layer.