Anti-corruption layers isolate legacy systems rather than decouple changes
Anti-corruption layers are designed to prevent domain model pollution from legacy systems, not to decouple routine business changes. Building generic translation layers for every layer boundary is often counterproductive and should be introduced lazily.
The speaker distinguished between using translation layers to decouple changes and using Anti-Corruption Layers, or ACLs, to prevent model pollution. In Domain-Driven Design, an ACL is used when integrating with legacy systems, such as mainframe models with bit-frame semantics, to ensure the new system's domain model is not corrupted by the old system's poor design. The speaker argued that ACLs are not primarily for decoupling changes, as legacy models rarely change significantly. Instead, they serve to isolate the new system from the 'Big Ball of Mud' of the old system.
In contrast, introducing separate data models for UI, Logic, and Database layers to decouple changes is often counterproductive. Typical business changes, such as adding a customer birth date, propagate through all layers anyway, making the overhead of constant data copying unnecessary. The speaker advised against building these translation layers 'on spec' and suggested introducing them lazily only when a specific need arises. Adding them later is not significantly harder than adding them upfront, and this approach avoids the inefficiency of maintaining unnecessary abstraction layers. The speaker summarized the purpose of the pattern by stating that the Anti-Corruption Layer exists to avoid corruption, not to manage routine change propagation.