We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 9-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your team builds a clean new Order Service. Proper domain model, named aggregates, ubiquitous language, everything by the book. Then you need to integrate with the 15-year-old inventory system.
The inventory system's API returns data like this: { "ITM_CD": "A7X-992", "QTY_OH": 47, "WHSE_LOC": "B3-R14", "LST_UPD": "20260104" }. Field names are cryptic abbreviations from the 1990s. Dates are strings in a non-standard format. Quantities can be negative (meaning "on backorder"), a domain concept buried in a data hack.
If you let this data structure leak into your Order Service, your clean domain model is now contaminated. Your code is full of item.ITM_CD instead of product.sku. Business logic decodes negative quantities. Date parsing scattered everywhere. The legacy system's bad design decisions have corrupted your new system's model.
Eric Evans described this problem in Domain-Driven Design (2003): when a bounded context integrates with another context that uses a fundamentally different model, the foreign model will infect your code unless you explicitly defend against it.
The Anti-Corruption Layer (ACL) prevents this. It sits between your clean system and the messy external system, translating between the two models. Your Order Service never sees ITM_CD. It sees Product { sku, quantity, warehouseLocation, lastUpdated } in your domain's language.
The Anti-Corruption Layer is a translation boundary between two bounded contexts, typically between your new system and a legacy or third-party system that uses a different model.
| ACL Component | Responsibility |
|---|---|
| Facade | Simplifies the external system's interface into something your system can call easily |
| Adapter | Converts the external system's data structures into your domain's data structures |
| Translator | Maps between the external system's vocabulary and your ubiquitous language |
The translation is bidirectional:
{ ITM_CD: "A7X-992", QTY_OH: 47 } -> ACL translates to { sku: "A7X-992", quantity: 47 } -> Your service receives clean domain objects.{ sku: "A7X-992", reserved: 5 } -> ACL translates to { ITM_CD: "A7X-992", QTY_RSRV: 5 } -> External system receives its expected format.Your domain code never contains external system terminology. The translation is isolated in the ACL.