Bounded Context

Le pattern stratégique fondateur du DDD : un modèle est cohérent à l'intérieur d'une frontière, et incohérent dès qu'on la franchit sans traduction.

Problème

Dans un grand hub EDI, le mot « commande » n'a pas le même sens selon qui parle. Pour les acheteurs, c'est un PurchaseOrder avec un état « ouvert / approuvé / livré » et porte la promesse d'achat. Pour la finance, c'est une obligation contractuelle qui génère une Invoice. Pour la logistique, c'est un Despatch avec des dates de livraison. Quand on tente de modéliser « la commande » en un schéma JSON global qui réunit tout, chaque équipe se bat pour imposer ses champs : 60 attributs, 30 enums conflictuels, une équipe paralysée à chaque modification.

Forces

• Le langage métier diverge entre équipes. Une « commande approuvée » signifie validée par l'acheteur (achats), mais comptabilisée comme engagement (finance), mais expédiable (logistique).
• Les cycles de release diffèrent. Achats livre mensuellement, finance trimestriellement, logistique en continu. Un modèle commun bloque tout le monde.
• Les contraintes externes diffèrent. Achats négocie avec les fournisseurs, finance respecte la norme comptable, logistique optimise la flotte.
• Un modèle universel n'existe pas. Tenter de construire unmodèle unifié finit par produire un objet vide de sens : chaque équipe ignore les attributs des autres.

Solution

Identifier les contextes bornés du domaine, leur donner un nom explicite (Achats, Facturation, Logistique, Audit), et définir pour chacun son propre modèle métier — son ubiquitous language. Aux frontières entre contextes, on instaure un Context Map : traducteurs explicites (Anti-Corruption Layer), partages négociés (Shared Kernel), relations conformistes ou customer-supplier. Chaque équipe propriétaire d'un contexte évolue son modèle à sa cadence.

┌────────────────────────────┐         ┌────────────────────────────┐
│ Contexte Achats (Purchase) │         │ Contexte Facturation       │
│ ──────────────────────────  │         │ ──────────────────────────  │
│ PurchaseOrder              │ ──ACL──▶│ Invoice                    │
│   poNumber : "PO-12345"    │ Trans-  │   invoiceNumber : "INV-99" │
│   buyerId, supplierId      │ lator   │   debtor, creditor         │
│   deliveryDate             │         │   paymentTerms             │
│   "ouvert", "approuvé"     │         │   "à émettre", "envoyée"   │
│                            │         │   "payée"                  │
└────────────────────────────┘         └────────────────────────────┘
   ORDERS EDIFACT D.96A                    INVOIC EDIFACT D.96A

Implémentation EDI

Cas concret : un hub EDI hospitalier sépare le contexte « Patient Administration » (HL7 ADT, qui définit « patient » comme une identité administrative avec adresse, couverture sociale, prochain de parenté) du contexte « Clinical Orders » (HL7 ORM, qui définit « patient » comme un sujet d'examen avec poids, allergies, prescriptions actives). Les deux contextes ne partagent qu'un identifiant pivot (MRN). Un Anti-Corruption Layer (translator) traduit ADT^A08 vers les modèles nécessaires en Clinical Orders. Pareil côté retail : ORDERS EDIFACT (contexte achats) ≠ ASN/DESADV (contexte logistique) ≠ INVOIC (contexte facturation). Chaque contexte a son équipe, ses règles de validation, son partnerId mapping. Le hub EDI est l'infrastructure du Context Map.

Anti-patterns

• Big Ball of Mud. Un seul modèle plat partagé entre toutes les équipes : chaque changement casse les autres, personne n'est responsable.
• Contextes calqués sur l'organigramme. Les contextes doivent suivre la cohérence métier, pas l'organisation RH. Sinon, la frontière bouge à chaque réorg.
• Contextes sans frontière explicite. Si on ne sait pas où finit « Facturation » et où commence « Achats », les concepts fuient (commande qui devient facture sans traduction).

Patterns liés

• Anti-Corruption Layer — le traducteur défensif aux frontières de contexte.
• Ubiquitous Language — la langue partagée à l'intérieur d'un contexte.
• Aggregate — la frontière de cohérence transactionnelle à l'intérieur d'un contexte.
• Modèle canonique — la traduction technique entre contextes/partenaires.
• Data Mesh — la généralisation Dehghani du Bounded Context au monde data.

Sources

• Evans E. — Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley 2003. Chap. 14 « Maintaining Model Integrity » — la définition originale du Bounded Context.
• Vernon V. — Implementing Domain-Driven Design, Addison-Wesley 2013. Chap. 2 et 3 développent la stratégie de découpage en contextes. informit.com — Implementing DDD
• Fowler M. — BoundedContext (martinfowler.com 2014). La synthèse pédagogique du pattern. martinfowler.com — BoundedContext
• Plotkin H. — Context Mapping. Le compagnon visuel du Bounded Context. github.com/ddd-crew/context-mapping