Contextes délimités et cartographie des contextes

Les modèles tactiques représentent les objets au sein d’un domaine ; le DDD stratégique détermine comment diviser un grand système en éléments capables d’évoluer indépendamment. Le concept central est le contexte délimité — une frontière explicite à l’intérieur de laquelle un modèle de domaine et son langage restent cohérents. La cartographie des contextes décrit les relations entre ces contextes. Cela a souvent plus d’impact que la conception d’une seule classe.

Au sein d’un contexte délimité, l’équipe partage un langage omniprésent — les mêmes termes sont employés dans les conversations, le code et le modèle. La difficulté est qu’un mot peut avoir des sens différents selon le contexte. Un Customer dans le domaine des Ventes (prospects, réductions) n’est pas le même qu’un Customer dans l’Assistance (demandes, accords de niveau de service). Un contexte délimité rend cette frontière explicite au lieu d’imposer un modèle partagé hypertrophié.

Un même concept métier reçoit un modèle propre à son contexte. Un Product dans le Catalogue s’intéresse aux descriptions et aux supports multimédias ; dans le Stock, il s’intéresse aux quantités disponibles et à l’emplacement. Chaque contexte ne définit que ce dont il a besoin.

Essayer de faire servir un Customer de référence à toutes les équipes produit une classe fourre-tout aux exigences contradictoires, des conflits entre équipes et des évolutions fragiles. Les contextes délimités permettent à chaque équipe de posséder son modèle et son langage, de déployer indépendamment et de traduire aux frontières. C’est à la frontière que vous payez un petit coût d’intégration pour éviter un coût de couplage bien plus élevé.

Une carte de contexte est une représentation générale de vos contextes délimités et des relations qui les unissent. Elle consigne à la fois l’intégration technique et la relation entre équipes et rapports de force (qui dépend de qui, qui peut imposer les changements). Le DDD nomme plusieurs modèles de relations récurrents, que nous allons examiner maintenant.

Les relations sont souvent orientées — un contexte en amont influence un contexte en aval (Customer/Fournisseur, Conformiste, Couche anticorruption). Un contexte aval conformiste n’a aucun moyen d’action et adopte donc simplement le modèle du contexte amont tel quel : il consomme directement la structure étrangère, en acceptant le couplage.

Un ACL traduit un modèle externe ou ancien dans le modèle propre à votre contexte, afin qu’aucun concept étranger ne puisse leak vers l’intérieur. Il s’agit du motif Adaptateur appliqué à une frontière de contexte, qui protège votre langage omniprésent.

• Noyau partagé : deux contextes partagent un petit sous-ensemble détenu conjointement (ci-dessous, un type Money commun) — ne le modifiez qu’après accord.
• Partenariat : deux équipes réussissent ou échouent ensemble.
• Voies séparées : l’intégration n’en vaut pas le coût.
• Service d’hôte ouvert / Langage publié : le contexte amont propose un protocole stable et documenté à de nombreux consommateurs.

Concrètement, les contextes s’intègrent au moyen de contrats bien définis : une méthode de traduction, un client d’interface de programmation encapsulant un langage publié ou des messages. Le côté récepteur convertit l’objet de transfert de données étranger dans son propre modèle afin que le couplage s’arrête à la frontière.

Les contextes délimités correspondent naturellement aux unités de déploiement : un monolithe modulaire aux frontières de modules claires ou des microservices séparés. La frontière doit être tracée autour de la capability métier, et non autour des couches techniques. Des microservices qui divisent un seul contexte fortement couplé créent un monolithe distribué ; des frontières de contexte bien alignées produisent des services qui évoluent indépendamment.

En pratique, un moyen efficace pour que les contextes s’intègrent sans partager leurs modèles consiste à échanger des événements. Le contexte amont publie un événement réduit et stable (un langage publié) ; le contexte aval s’y abonne et le convertit dans son propre modèle — sans jamais importer les classes du contexte amont.

Relations entre contextes.

Vous êtes passé du DDD tactique au DDD stratégique. Un contexte délimité est la frontière à l’intérieur de laquelle un modèle et son langage omniprésent restent cohérents, ce qui libère les équipes d’un modèle partagé hypertrophié. Une carte de contexte documente les relations — Customer/Fournisseur, Conformiste, Couche anticorruption, Noyau partagé, Partenariat, Voies séparées, Service d’hôte ouvert/Langage publié — en consignant à la fois l’intégration technique et la dynamique des équipes. Tracez les frontières autour des capacités métier, traduisez aux frontières et votre système pourra évoluer en parties déployables indépendamment.