A card platform integrates with a network whose data model and semantics differ fundamentally from its own. Where should the translation live and what discipline does it require?
Show the full answer Hide the answer
Where it lives
At the boundary, and nowhere else. The layer speaks the external system's model on one side and your domain model on the other, and it is the only component that knows the external system exists.
The discipline that makes it work: the external model stops there. The moment its field names, status codes, identifiers or assumptions appear in the domain model, the external system's constraints have become permanent — and they will outlive the integration.
What it owns
Everything peculiar about the external system: the meaning of a numeric status code, the fact that a blank field means unknown rather than empty, the almost-standard date format, an identifier unique only within a product line, and the mapping from the external error taxonomy into your own.
That mapping is the real integration work, and it is provider-specific code that must be tested against recorded real responses — because provider documentation is frequently incomplete and occasionally wrong about its own error codes.
The error taxonomy it must produce
Four categories, because the consuming system needs to know whether an operation can be retried and whether its outcome is known: definitely failed and retryable, definitely failed and terminal, definitely succeeded, and unknown — which is the category most systems omit and the one that causes duplicate authorisations.
A timeout does not mean the operation failed; it means you do not know, and the layer must surface that distinction rather than collapsing it.
Why it survives the integration
An anti-corruption layer is not scaffolding. When the external provider is replaced, the layer is replaced and the domain is untouched — which is its entire value and is only realised if the discipline held.
Teams that treat it as temporary write it carelessly, let the external model leak, and then find that switching providers means rewriting the core.
The generalisation
Any constraint with an expiry date deserves a boundary. A vendor relationship, a jurisdiction-specific rule, a legacy system, a partner's format — each will change, and the layer is what converts a rewrite into a replacement.
A constraint that is genuinely permanent — a law of physics, an exchange's opening hours — does not, and putting a boundary around everything produces a system where nothing is direct.