In a cloud migration where a new set of microservices is being built to gradually replace an on-premises monolith, how does an Anti-Corruption Layer typically get deployed and operated as a cloud integration pattern, and how does that differ from its original description as a Domain-Driven Design concept?

## One idea, two framings The Anti-Corruption Layer as most engineers encounter it in cloud and microservices work is a direct descendant of a concept from **Domain-Driven Design (DDD)**, but the way it gets built and operated in a cloud migration looks meaningfully different from its original, more code-level description, mostly because of where the boundary physically sits and what crosses it. ## The DDD origin In its DDD origin, an ACL describes how one **bounded context** - a part of a system with its own internally consistent domain model and ubiquitous language - protects itself when it needs to consume or integrate with another bounded context whose model is different, whether that's a legacy subsystem, a different team's service, or a third-party system. The emphasis there is squarely on the model: - bounded contexts and context mapping are the theoretical framework for deciding which contexts talk to each other and how; - the Anti-Corruption Layer is one of several relationship patterns (alongside things like shared kernel, conformist, or open host service) available at the boundary between two bounded contexts, chosen when the downstream context needs to actively translate rather than simply conform to the upstream model. In this framing, an ACL might be nothing more than a package of translator classes living inside a single application's codebase, invisible to anyone outside that team. ## The cloud-integration framing When the same idea shows up as a cloud design pattern - for instance, in the way cloud architecture guidance such as Microsoft's Azure Architecture Center catalogs it - the emphasis shifts from 'which bounded context owns which model' to 'how do you physically and operationally isolate a new cloud-native system from an old, foreign one during a migration.' Concretely, in a cloud migration scenario, an organization moving an on-premises monolith to cloud-native microservices will often deploy the ACL as its own standalone component: - a small facade service running in the cloud (or at the network edge between on-prem and cloud), - an API gateway with custom routing and transformation rules, - or occasionally a sidecar deployed alongside a new service specifically to handle the legacy-facing traffic. This is very commonly paired with the **strangler fig** pattern: as functionality is rebuilt in the new cloud-native services, the ACL is the switchboard that lets traffic for a given capability be incrementally cut over from the legacy system to the new one, translating in both directions during the transition period so that neither the new services nor any external clients need to know, request by request, which system is actually serving them. ## What a network-crossing component takes on Being a physically separate, network-crossing component introduces operational concerns that the original DDD description doesn't dwell on, because DDD's concern is model integrity, not infrastructure. A cloud-deployed ACL has to handle: 1. **Latency and partial failure** - real network latency and partial failure between the on-prem legacy environment and the cloud, often across a VPN or dedicated interconnect with its own reliability characteristics. 2. **Its own auth story** - it needs its own authentication and authorization story for calling into an on-prem system that may use older protocols (LDAP, Kerberos, a mainframe-specific auth scheme) that don't map cleanly onto cloud-native identity. 3. **Observability across the hybrid boundary** - it needs observability, logging, tracing, and metrics, that spans the hybrid boundary, so that a failure can be diagnosed as either an on-prem issue, a network issue, or a translation bug in the ACL itself. None of this is specific to the 'translate the model' idea at the heart of the pattern; it's the operational cost of that idea being realized as a distributed system component rather than an in-process library. ## Where the two framings diverge It's worth being precise about where the two framings diverge and where they don't, because in interviews this distinction is easy to blur. - **The core mechanism is shared.** They don't diverge on it: both are about a translation boundary that keeps a foreign model from leaking into a protected one, using a facade and translators. - **Emphasis and packaging.** DDD's treatment is about the modeling decision - when and why a bounded context should actively translate rather than conform - and the deeper theory of bounded contexts and context mapping that justifies that decision is squarely DDD territory, not something the cloud-patterns framing re-derives. The cloud-integration framing takes that modeling decision as a given and focuses on how to realize it as a deployable, observable, network-spanning piece of infrastructure suited to a real migration timeline. In practice, most teams doing a cloud migration don't need to resolve deep bounded-context theory to build an effective ACL - they need to correctly identify that the legacy system's model shouldn't be trusted directly, then apply the infrastructure and operational discipline described above, while treating the DDD literature as the place to go if the underlying modeling questions (where exactly should context boundaries be drawn, is this really an ACL relationship or something else) need deeper justification.