Context Mapping

Version 1.1 — 2026-05-10

Objectifs : comprendre le Context Mapping du Domain‑Driven Design (DDD), savoir identifier des Bounded Contexts, décrire leurs relations stratégiques et choisir le bon pattern d'intégration.

1. Intérêts du Context Mapping

Les intérêts du Context Mapping sont:

Clarifier les frontières entre domaines
Rendre l’intégration explicite (et plus sûre)
Aligner les équipes et la communication
Préserver la cohérence des modèles
Éclairer les décisions d’architecture
Réduire la complexité à long terme

Il s'agit d'une vue sociotechnique : le code reflète la façon dont les équipes parlent, négocient et coopèrent.

2. Périmètre : ce qu'on cartographie, ce qu'on ignore

Une Context Map sert à raisonner sur les frontières sémantiques et les rapports de force entre sous‑systèmes. Elle ne décrit ni leur intérieur ni leur infrastructure.

Les éléments pris en compte sont:

Les contextes délimités
Le sens de l’influence (Upstream / Downstream)
Les patterns stratégiques (ACL, OHS, Partnership…)
Les termes pivots de l’Ubiquitous Language
Les frontières organisationnelles entre équipes

Règle d'or : si un détail technique change demain, la carte ne devrait pas changer. Par contre, elle doit changer quand le contrat métier entre deux contextes change.

3. Le concept central : le Bounded Context

Un Bounded Context (contexte délimité) est une zone du système à l'intérieur de laquelle :

Un vocabulaire (l'Ubiquitous Language) a un sens cohérent et unique.
Un modèle est valable, applicable, et autoritaire.
Une équipe (ou un petit groupe d'équipes) en est responsable.

Définition opérationnelle : « le périmètre à l'intérieur duquel un mot veut dire ce qu'il veut dire ».

3.1 Frontières des contextes délimités

Les frontières d'un Bounded Context suivent le langage humain. Là où un mot change de sens, la frontière passe.

Trois contextes, trois définitions différentes du « Client ». Aucune n'est fausse — chacune est vraie dans son contexte.

3.2 Déterminer les frontières

Trois heuristiques permettent de détecter les frontières des contextes.

#	Heuristique	Source	En une phrase
1	Polysémie	Fowler, INNOQ, Donkey	Un même mot change de sens → frontière probable.
2	Événements pivots	OpenKnowledge, SAP	Un événement clé clôt un bloc dont l'ordre interne est indifférent.
3	Pas de partage entre équipes	INNOQ, OpenKnowledge, DDD Crew	Une équipe peut gérer plusieurs contextes, mais pas le contraire.

D'autre part si, dans l'évolution du système, un détail technique change, la carte ne devrait pas changer. Par contre, elle doit changer quand le contrat métier entre deux contextes change.

3.3 Concepts uniques vs. concepts partagés

Concept unique : n'existe que dans un seul contexte. Ex. : un Ticket de support n'a aucun sens en Marketing.
Concept partagé : porté par plusieurs contextes, avec un modèle propre à chacun. Une traduction explicite est nécessaire à la frontière. Ex. : Client, Produit, Commande.

Règle : un concept partagé n'est pas une classe partagée. C'est trois classes différentes qui se correspondent à la frontière.

4. L'Ubiquitous Language : le langage qui définit la frontière

L'Ubiquitous Language (UL — « langage omniprésent ») est le vocabulaire développé conjointement par les développeurs et les experts métier au sein d'un Bounded Context.

4.1 Le principe fondamental

Même sens ⟺ même contexte ; sens différent ⟺ contexte différent.

Le langage est l'indicateur de frontière. Quand vous entendez deux personnes employer le même mot avec des sens visiblement incompatibles, vous regardez deux contextes différents — qu'ils soient déjà séparés dans le code ou pas encore.

4.2 L'UL est local, jamais global

Erreur classique : vouloir un « glossaire d'entreprise » unique. Cette ambition échoue toujours, car elle nie un principe fondamental observé sur le terrain : un langage émerge naturellement à l'échelle d'une équipe. Tenter de l'imposer plus haut dilue le sens et freine l'autonomie.

4.3 Application cohérente

L'UL doit apparaître partout dans son contexte :

Un terme qui n'apparaît que dans la documentation mais pas dans le code est un signal : soit il est obsolète, soit il vit dans un autre contexte.

5. La Context Map : carte des frontières

La Context Map est le diagramme qui répond à trois questions, et seulement trois :

Quels Bounded Contexts existent ?
Comment sont ils liés (quel pattern, quelle direction) ?
Où vit la traduction des concepts partagés ?

C'est une carte stratégique. Elle ne dit pas comment un contexte est implémenté ; elle dit où sont les frontières et comment on les franchit.

5.1 Plusieurs cartes valent mieux qu'une

Une grande carte exhaustive est presque toujours illisible. Préférez plusieurs cartes ciblées, chacune répondant à une question précise :

Carte des dépendances de l'équipe Paiement.
Carte des intégrations vers le legacy ERP.
Carte des contextes touchés par la GDPR.

5.2 Une carte est vivante

Les patterns évoluent avec la structure d'équipe, la confiance entre groupes, les changements de propriété. Une carte qui n'est pas réévaluée régulièrement ment.

6. Sens de l'influence : Upstream / Downstream / Free

Avant de choisir un pattern, il faut qualifier la nature de la relation entre deux contextes. DDD distingue trois cas.

6.1 Mutually Dependent — mutuellement dépendants

Les deux contextes ont besoin l'un de l'autre pour réussir. Une livraison de l'un sans l'autre n'a pas de sens.

→ Pattern associé : Partnership (ou Shared Kernel en cas de couplage très fort).

6.2 Upstream / Downstream — amont / aval

L'Upstream (U, amont) peut réussir sans le Downstream (D, aval). Les décisions de l'amont impactent l'aval ; l'inverse n'est pas vrai.

→ Patterns associés : Customer‑Supplier, Conformist, ACL, OHS / Published Language.

6.3 Free — libre

Aucun lien organisationnel ou technique significatif. Les changements de l'un n'affectent pas l'autre.

→ Pattern associé : Separate Ways.

Astuce de diagnostic : demandez « Si l'équipe X disparaissait demain, l'équipe Y pourrait‑elle continuer ? ». La réponse classe la relation.

7. Les neuf patterns de Context Map

On les regroupe en trois familles de réponse au sens de l'influence : coopération forte, relation asymétrique, et évitement.

7.1 Famille A — Coopération forte

Pattern 1 — Partnership (Partenariat)

Deux équipes mutuellement dépendantes coordonnent planning et releases. Les fonctionnalités interdépendantes sont livrées ensemble.

Signal : un échec d'un côté entraîne l'échec de l'autre.
Quand : objectifs produits partagés, faible latence de communication, sessions de planification conjointes possibles.
Risque : dès que la communication se dégrade, le pattern dérive silencieusement vers Customer‑Supplier sans que personne n'ajuste les contrats — d'où des pannes d'intégration soudaines.

Pattern 2 — Shared Kernel (Noyau partagé)

Les deux contextes désignent un sous‑ensemble explicite du modèle qui leur est commun (un module, une bibliothèque, un schéma). Toute modification doit être négociée.

Signal : deux contextes partagent du code ou un schéma.
Règles de survie : garder le kernel minuscule, tests d'intégration à chaque modification, équipes au niveau Partnership.
Souvent : une mesure temporaire lors d'une modernisation.

Mise en garde : un Shared Kernel non discipliné devient le couplage le plus dangereux du système — chaque équipe le tire à elle.

7.2 Famille B — Relation asymétrique

C'est la famille la plus fréquente : la majorité des relations inter‑équipes sont déséquilibrées.

Pattern 3 — Customer / Supplier (Client / Fournisseur)

Relation Upstream‑Downstream formalisée où le Client a un vrai pouvoir de négociation : ses besoins entrent dans le backlog du Fournisseur.

Signal : le Downstream peut négocier, prioriser, refuser.
Quand : équipes internes avec SLA, ou client unique du fournisseur.

Pattern 4 — Conformist (Conformiste)

Le Downstream adopte intégralement le modèle de l'Upstream, sans traduction. Aucune négociation possible.

Signal : API tierce non influençable, legacy imposé.
Quand : modèle upstream raisonnablement adapté, domaine non‑core pour vous.
Risque majeur : si la conformité s'étend à un domaine core, le modèle interne devient « le miroir des problèmes de quelqu'un d'autre ».

Pattern 5 — Anticorruption Layer / ACL (Couche anti‑corruption)

Le Downstream installe une couche de traduction qui isole son modèle du modèle Upstream. C'est l'inverse du Conformist : on dit « non » diplomatiquement.

Signal : vous touchez un legacy, ou un Upstream « pollué », et vous protégez un domaine core.
Coût : implémenter et maintenir le traducteur.
Bénéfice : votre Ubiquitous Language reste propre ; seule l'ACL connaît la complexité externe.

Mécaniques de traduction :

Stateless : chaque message ou requête est mappé indépendamment.
Stateful : le traducteur agrège, combine ou consolide. Il devient alors un mini Bounded Context dédié à l'intégration.

Pattern 6 — Open Host Service / OHS (Service hôte ouvert)

L'inverse de l'ACL, vu côté Upstream : ce dernier expose un protocole standardisé pensé pour l'intégration de plusieurs consommateurs.

Signal : API publique ou plateforme avec multiples clients.
Quand : l'Upstream a la maturité de concevoir un contrat public stable et de le faire évoluer (versionner) sans casser les consommateurs.

Pattern 7 — Published Language / PL (Langage publié)

Un langage de domaine documenté et partagé, qui exprime ce qui doit circuler entre contextes. Souvent couplé à OHS.

Exemples standards : iCalendar, vCard, HL7, OpenBanking.
Signal : format d'échange formel, contrat versionné.

OHS + PL est « la façon la plus propre de scaler les intégrations autour d'un service central ».

7.3 Famille C — Évitement

Pattern 8 — Separate Ways (Chemins séparés)

Deux contextes choisissent explicitement de ne pas s'intégrer. La duplication est moins coûteuse que l'intégration.

Signal : coût d'intégration > bénéfice.
Quand : domaines périphériques ou génériques, équipes désalignées.
Rare pour des domaines core.

Pattern 9 — Big Ball of Mud (Grande boule de boue)

Un système (ou un sous‑système) aux frontières floues, aux modèles mélangés, à la dette technique massive. Ce n'est pas un pattern à adopter : c'est un anti‑pattern à contenir.

Action : entourer la boule d'une ACL pour empêcher sa contagion vers les contextes voisins.

8. Choisir un pattern : arbre de décision

Quatre axes de décision suffisent pour 90 % des cas.

Axe	Question
Force de collaboration	Les équipes communiquent‑elles fréquemment ? Objectifs partagés ?
Équilibre des pouvoirs	Qui contrôle le contrat ? Qui doit s'adapter ?
Criticité du domaine	Est‑ce un domaine core ou périphérique ?
Qualité du modèle amont	Le modèle Upstream est‑il propre ou hérité / pollué ?

8.1 Arbre de décision simplifié

8.2 Tableau de synthèse

Pattern	Relation	Qui contrôle	Traduction	Usage type
Partnership	Mutuellement dép.	Partagée	Négociée	Équipes co‑localisées, mêmes buts
Shared Kernel	Couplage fort	Partagée	Code commun	Modernisation, mono‑repo
Customer‑Supplier	U / D négocié	Upstream (influençable)	À la frontière	Équipes internes avec SLA
Conformist	U / D non négocié	Upstream (intransig.)	Aucune	API tierce, legacy externe
ACL	U / D, défense aval	Downstream	Couche dédiée	Domaine core face à legacy
OHS + PL	U / D, exposition	Upstream	Contrat publié	Plateforme multi‑consommateurs
Separate Ways	Aucune	N/A	Aucune	Domaines périphériques
Big Ball of Mud	Anti‑pattern	—	Contenir via ACL	Legacy chaotique à isoler

9. Évolution des patterns dans le temps

Un pattern est une photographie. Les relations dérivent en fonction des changements humains et organisationnels.

Transition observée	Déclencheur typique
Partnership → Customer‑Supplier	Équipes séparées par fuseau ou ligne organisationnelle
Customer‑Supplier → Conformist	Le Downstream cesse d'être consulté
Conformist → ACL	Le Downstream devient un domaine core et veut se protéger
Shared Kernel → Customer‑Supplier	Le kernel grossit, devient ingérable, on le scinde
N'importe quoi → Separate Ways	Coût de collaboration > bénéfices

Bon réflexe : réviser la Context Map à chaque réorganisation d'équipes ou changement majeur de propriété. Les frictions d'intégration sont presque toujours le symptôme d'un pattern obsolète.

10. Notation visuelle d'une Context Map

Il n'existe pas de standard rigide. Une convention répandue, suffisante pour 99 % des cas :

Chaque Bounded Context est une boîte arrondie.
Une flèche pleine indique le flux de modèle (de l'Upstream vers le Downstream).
Les étiquettes U, D, OHS, ACL, PL, SK, PT, CF, C, S annotent les rôles.
Une boîte spéciale /ACL/ ou OHS est posée à la frontière où vit la traduction.

Avec Mermaid :

Lecture : Ventes subit le modèle de l'ERP (Conformist), expose une API publique vers Support (OHS), et négocie avec Facturation. Support protège son modèle de l'ERP via une ACL.

Disclaimer — Initialement, ce document condense automatiquement 12 sources collectées le 2026-05-08. Depuis, il est enrichi par les retours de lecture et d'expériences sur le terrain.