Anti-Corruption Layer

La frontière défensive qui empêche les concepts d'un système externe de polluer le modèle métier interne — une digue stratégique au DDD.

Problème

Un hub EDI moderne s'interface avec un ERP legacy SAP installé depuis 25 ans. Le modèle SAP utilise des codes propres : BUKRS pour société, WERKS pour usine, LFART pour type de livraison, état "E0008" pour « commande approuvée mais pas livrée ». Si le hub EDI laisse ces codes envahir ses services internes, chaque ligne de code métier doit connaître les codes SAP. Un changement de modèle ERP devient une refonte complète. Pire : le modèle EDIFACT du partenaire Walmart utilise d'autres codes, et le mélange des deux donne un modèle interne hybride incompréhensible.

Forces

• Les modèles externes sont hors de notre contrôle. Vendor lock-in (SAP), partenaire commercial (Walmart), norme réglementaire (HL7 FHIR) — leur évolution suit leur agenda.
• Les modèles externes ont 30 ans de dette. Codes cryptiques, valeurs spéciales, exceptions historiques : laisser fuiter dans le modèle interne pollue.
• Plusieurs externes coexistent. SAP + Oracle EBS + Salesforce + 50 partenaires EDI : un modèle interne unique doit absorber tout sans en porter la signature.
• La traduction a un coût. Performance (mapping par message), maintenance (table des correspondances), précision (pertes potentielles).

Solution

Construire un Anti-Corruption Layer entre le contexte interne et chaque système externe. L'ACL combine plusieurs patterns classiques : une Façade qui simplifie l'API externe, un Adapter qui adapte la signature technique, un Translator qui convertit les concepts métier. Tout ce qui sort de l'ACL vers le contexte interne parle l'ubiquitous language interne ; tout ce qui sort de l'ACL vers l'externe parle le langage de l'externe. L'ACL est la membrane.

┌────────────────────────────────┐
│  Bounded Context : Notre hub   │
│  domain.Invoice {              │
│    invoiceId, debtor,          │
│    creditor, lines[]           │
│  }                             │
└────────────────────────────────┘
              ▲
              │ Traducteur (Façade + Adapter + Translator)
              │
   ┌──────────┴──────────────────────────────────────┐
   │ Anti-Corruption Layer                           │
   │  - parser EDIFACT INVOIC D.96A                  │
   │  - mapping UN/EDIFACT codes ↔ enum interne      │
   │  - validation entrée vs schéma partenaire       │
   │  - traduction RFF SBDH ↔ champ interne          │
   └─────────────────────┬───────────────────────────┘
                         │
              ┌──────────▼──────────┐
              │  Partenaire EDI     │
              │  INVOIC D.96A brut  │
              │  + ses quirks       │
              └─────────────────────┘

Implémentation EDI

Cas concret : un hub EDI reçoit un INVOIC EDIFACT D.96A d'un partenaire Walmart. Le partenaire utilise des codes UN/EDIFACT pour « type d'unité d'emballage » et son propre numéro de TVA américain (EIN). L'ACL fait : (1) parsing EDIFACT structurel ; (2) validation contre le schéma D.96A et les contraintes Walmart Implementation Guide ; (3) mapping codes UN/EDIFACT vers énumérations internes ; (4) lookup EIN → ID partenaire interne ; (5) émet un événement InvoiceReceived dans le langage interne. Aucun service en aval n'a besoin de connaître l'EDIFACT. Si Walmart impose un nouveau qualifier en 2027, seul l'ACL est touché. Pareil côté SAP : un connecteur IDoc adapte les structures SAP en modèles internes. Sterling B2B Integrator est typiquement déployé comme ACL devant un SAP.

Anti-patterns

• ACL squelettique. Une simple traduction littérale champ par champ : les concepts externes traversent avec un autre nom. La pollution est juste renommée.
• ACL business logic. Y mettre des règles métier (« si creditTerm > 30 alors flagger ») duplique la logique du domaine interne, et le hub ACL devient un mini-domaine concurrent.
• Pas d'ACL pour un partenaire stratégique. « Walmart est notre plus gros client, on s'aligne sur leur modèle » : le jour où on en ajoute un autre, on découvre que le modèle interne est en réalité celui de Walmart.
• ACL bidirectionnel mal pensé. ACL pour entrée et pour sortie : les deux directions peuvent avoir des règles différentes. Préciser quel sens est défendu.

Patterns liés

• Bounded Context — l'ACL est la frontière entre contextes.
• Message Translator — la brique EIP de traduction message-à-message.
• Modèle canonique — l'output cible typique d'un ACL hub.
• Adapter — sous-pattern technique de l'ACL.
• Normalizer — la porte d'entrée typique d'un ACL multi-format.

Sources

• Evans E. — Domain-Driven Design, Addison-Wesley 2003. Chap. 14 §3 « Anti-corruption Layer ».
• Microsoft Architecture Center — Anti-Corruption Layer pattern. learn.microsoft.com — ACL
• Vernon V. — Implementing Domain-Driven Design, Addison-Wesley 2013. Chap. 13 développe le pattern avec des exemples concrets de mapping ERP/CRM.
• Strangler Fig + ACL (Fowler). La combinaison classique pour décommissionner progressivement un legacy via un ACL hub. martinfowler.com — StranglerFigApplication