Domaines, sous-domaines et Bounded Contexts

Comment distinguer les problèmes métier des modèles que l’on conçoit pour les résoudre ?

Introduction

Trois notions qu'il ne faut pas confondre.

Les termes domaine, sous-domaine et Bounded Context apparaissent souvent ensemble dans les discussions sur le DDD. Ils peuvent sembler désigner trois niveaux d'un même découpage. Ce serait pourtant confondre la manière dont on comprend le métier avec la manière dont on conçoit les modèles qui le représentent.

Une entreprise parle de produits, de clients, de commandes, de prix ou de stocks. Ces mots semblent désigner des réalités évidentes. Il serait donc tentant de leur associer un modèle unique, partagé par toutes les applications et toutes les équipes, afin d'éviter les duplications.

Cette intuition a ses limites. Le modèle dont un vendeur a besoin pour conclure une vente n'est pas nécessairement celui qu'utilise un préparateur pour constituer un colis ou celui dont a besoin un comptable pour établir une créance. Les trois peuvent travailler à partir d'une même réalité, sans s'intéresser aux mêmes faits, aux mêmes comportements ni aux mêmes règles.

Le DDD ne propose pas de renoncer à la cohérence du système d'information. Il propose de définir explicitement le périmètre dans lequel cette cohérence doit être assurée, puis d'organiser les relations entre les modèles.

Pour comprendre ce raisonnement, il faut distinguer le domaine, ses sous-domaines, le modèle métier et les Bounded Contexts. Ces notions ne désignent pas les mêmes choses et ne constituent pas quatre niveaux successifs d'une arborescence.

Cette distinction s'inscrit dans le design stratégique du DDD, notamment tel qu'il est présenté par Eric Evans ^[E1], Vaughn Vernon ^[V1] et Vlad Khononov ^[K1].

Domaine

Comprendre le métier avant de concevoir le logiciel

Eric Evans définit le domain comme un champ de connaissance, d'influence ou d'activité auquel un logiciel s'applique ^{[E1, « Definitions », p. vi]}.

Dans une entreprise de grande distribution alimentaire, le domaine considéré pourrait être le commerce et la distribution de produits alimentaires. Il recouvre une réalité plus vaste que les applications informatiques : des personnes, des règles commerciales, des processus, des contraintes réglementaires, des relations avec les fournisseurs et les clients, des événements et des décisions.

Le domaine n'est donc ni une base de données ni le périmètre d'une application. Il ne se découvre pas en examinant uniquement l'organigramme technique ou les dépôts de code.

Le mot « domaine » reste relatif au périmètre étudié. L'entreprise peut être vue à l'échelle de ses activités globales, tandis qu'une initiative plus ciblée se concentre sur une partie de celles-ci. Le choix de cette échelle doit être explicité, faute de quoi deux interlocuteurs peuvent employer le même terme pour désigner des périmètres différents.

Question directrice : dans quel univers métier se situe le problème que nous voulons résoudre ?

Avant d'imaginer comment découper un logiciel, il nous faut donc regarder plus finement les problèmes qui composent ce domaine.

Sous-domaines

Un métier, plusieurs problématiques à résoudre

Une activité d'entreprise est trop vaste pour être comprise et traitée comme un bloc indifférencié. Le subdomain désigne une partie du domaine, organisée autour d'une problématique ou d'une capacité métier identifiable.

Dans notre exemple de grande distribution, on pourrait notamment étudier :

la gestion du catalogue des produits ;
la tarification et les promotions ;
la prise de commande ;
la préparation des commandes ;
l'approvisionnement et les stocks ;
le paiement et l'encaissement ;
la fidélisation des clients.

Cette liste est une hypothèse de découpage métier, et non une carte de sous-domaines validée. La distinction entre, par exemple, la prise de commande et l'encaissement doit être confrontée aux processus et aux experts de l'entreprise.

La caractéristique essentielle d'un sous-domaine est qu'il relève du problème métier, non de son implémentation. Il existe comme objet d'analyse même si l'entreprise ne dispose d'aucun logiciel spécialisé pour le prendre en charge. Inversement, la présence de trois applications n'implique pas l'existence de trois sous-domaines.

Core, support et generics sub-domains

L'analyse stratégique différencie habituellement trois catégories :

Core subdomain : il contribue de façon distinctive à la stratégie ou à l'avantage concurrentiel de l'organisation.
Supporting subdomain : il est nécessaire au fonctionnement de l'activité mais ne constitue pas, à lui seul, une différenciation stratégique majeure.
Generic subdomain : il traite un problème largement commun à de nombreuses organisations et pour lequel des solutions existantes peuvent être pertinentes.

Ce classement n'est ni une mesure absolue de complexité ni une propriété éternelle du sous-domaine. Une capacité logistique peut être au cœur de la stratégie d'une entreprise et plus périphérique chez une autre. Sa classification peut évoluer avec les priorités métier.

Cette distinction oriente l'investissement et la façon de traiter les problèmes : elle ne prescrit pas automatiquement une architecture ou un niveau de sophistication technique ^{[V2, chap. 3 ; K2, chap. 1]}.

Question directrice : quels problèmes métier distincts l'entreprise doit-elle savoir résoudre, et lesquels sont stratégiques pour elle ?

Identifier ces sous-domaines clarifie quels problèmes l'entreprise doit résoudre. Mais cela ne décide toujours pas quel modèle utiliser pour chacun. Pour saisir ce second enjeu, il faut comprendre ce qu'est — et ce que n'est pas — un modèle métier.

Du problème métier à sa représentation : pourquoi un modèle ne suffit pas toujours

Le modèle métier : représenter sans tout reproduire

Avant d'introduire un Bounded Context, une notion intermédiaire est indispensable : le modèle métier.

Un modèle n'est pas une copie exhaustive de la réalité. C'est un ensemble d'abstractions qui retient les éléments utiles pour comprendre et résoudre un problème donné. Cette idée apparaît explicitement dans la définition du model par Evans ^{[E1, « Definitions », p. vi]}.

Un modèle métier ne se réduit donc pas aux colonnes d'une table, aux champs d'un DTO ou à une structure de classes. Il exprime aussi des concepts, des comportements, des règles, des invariants et des relations significatives.

Par exemple, parler d'une « commande » peut impliquer des questions différentes :

Quand est-elle considérée comme acceptée ?
Peut-on encore en modifier les lignes ?
Que signifie « annulée » ?
Qui a le droit de la modifier ?
Quels engagements ont été pris envers le client ?

Deux systèmes peuvent partager des champs identiques tout en répondant différemment à ces questions. Leurs modèles métier ne sont alors pas identiques. À l'inverse, deux écrans aux présentations différentes peuvent très bien reposer sur un seul et même modèle.

Un modèle est bon par rapport à l'usage auquel il est destiné, pas parce qu'il contient toutes les informations imaginables.

Modéliser ne consiste donc pas à reproduire toute la complexité du métier, mais à en retenir les distinctions essentielles pour le problème considéré. Cette simplification exige néanmoins une véritable compréhension du domaine. Car simplifier un modèle ne signifie pas ignorer sa complexité, au risque de tomber dans le simplisme. Une distinction que nous explorons plus largement dans Is KISS evil ?.

Le constat devient plus concret lorsque plusieurs modèles travaillent sur une réalité physique identique, mais doivent répondre à des contraintes différentes.

Un même réseau routier, plusieurs modèles de navigation

Imaginons une organisation dont le domaine étudié est la mobilité routière, et l'un de ses sous-domaines : le calcul d'itinéraires. Tous les systèmes travaillent sur les mêmes routes, intersections et voies. Mais la question change avec l'usage :

Quel trajet recommander à cette voiture ?
Quel trajet ce poids lourd est-il autorisé et capable d'emprunter, compte tenu de sa hauteur, de son tonnage ou des matières transportées ?
Quel trajet permet à ce véhicule de secours d'intervenir au plus vite, avec ses accès particuliers ?

« Route accessible » ou « meilleur itinéraire » n'ont donc pas la même définition opérationnelle, bien que le réseau observé soit le même.

Cela ne suffit pas à justifier trois Bounded Contexts, ni trois sous-domaines. Si la navigation poids lourds se résume à filtrer le même graphe selon un profil de véhicule, un modèle commun paramétré par ce profil suffit. Si la navigation des secours introduit des notions sans équivalent ailleurs — priorité d'intervention, accès réservés négociés avec les autorités, coordination avec un centre de régulation — et que ces règles évoluent sous l'autorité d'autres acteurs, un contexte distinct se justifie.

Vlad Khononov recourt lui aussi à l'idée de cartes différentes pour expliquer l'intérêt de plusieurs modèles répondant à des problèmes distincts ^{[K1, chap. 3, « The Interplay Between Subdomains and Bounded Contexts »]}.

Ce point est essentiel : plusieurs modèles ne prouvent pas, à eux seuls, l'existence de plusieurs sous-domaines ; plusieurs usages ne prouvent pas, à eux seuls, l'existence de plusieurs Bounded Contexts.

Si des modèles distincts ont de bonnes raisons d'exister, une question surgit : où chacun de ces modèles est-il valable, et comment éviter que leurs définitions se mélangent ? C'est à cette question que répond le Bounded Context.

Bounded Context

Donner des frontières à un modèle cohérent

Un Bounded Context est une frontière explicite à l'intérieur de laquelle un modèle métier est défini, compris et appliqué de manière cohérente.

Cette définition reprend le sens établi par Eric Evans dans sa DDD Reference ^{[E1, « Definitions », p. vi ; « Bounded Context », p. 2]}. Elle entraîne plusieurs conséquences :

Les termes métier doivent être interprétés dans le contexte du modèle qui les définit.
Les règles et les comportements s'expriment selon cette interprétation locale.
Les limites du contexte rendent explicite l'endroit où les hypothèses du modèle cessent d'être garanties.
Les échanges avec les autres contextes nécessitent une intégration qui respecte les modèles de chacun.

Le modèle est lié à un Ubiquitous Language, un langage partagé entre experts métier et développeurs, utilisé aussi bien pour discuter du problème que pour concevoir le logiciel. « Ubiquitaire » signifie ici dans le périmètre du contexte, pas « universel dans toute l'entreprise » ^{[E1 ; V1, chap. 2]}.

Un exemple de grande distribution : que signifie « produit » ?

Dans un contexte de catalogue, un produit peut être caractérisé par son identité commerciale, sa description, sa marque et ses caractéristiques.

Dans un contexte de commande, une ligne commandée doit conserver des éléments de l'engagement pris envers le client : désignation présentée au moment de l'achat, quantité, conditions tarifaires convenues, etc.

Dans un contexte de préparation, une référence à prélever peut être associée à un emplacement, un conditionnement, des substitutions possibles et des contraintes opérationnelles.

Ces représentations portent sur des réalités liées, mais le mot « produit » ne suffit pas à imposer un objet logiciel universel. Selon le modèle considéré, certaines propriétés ont du sens, d'autres sont secondaires, et les règles peuvent différer.

L'exemple illustre la pluralité des modèles d'un concept ; il ne démontre pas que « Catalogue », « Commande » et « Préparation » appartiennent au même sous-domaine. Ce sont deux questions distinctes.

Martin Fowler souligne également que des Bounded Contexts différents peuvent partager certains mots tout en leur associant des modèles distincts ^[F1].

Question directrice : dans quel périmètre ce langage et ce modèle métier restent-ils cohérents et font-ils autorité ?

Dès lors, la difficulté n'est plus seulement de nommer les contextes. Elle est de comprendre leur relation avec les sous-domaines : ces deux découpages doivent-ils nécessairement coïncider ?

Sous-domaine et Bounded Context : deux découpages qui ne se superposent pas toujours

La différence structurante est la suivante :

Notion	Ce qu'elle décrit	Nature	Question principale
Domaine	Le champ d'activité ou de connaissance considéré	Réalité métier à comprendre	De quoi parle-t-on ?
Sous-domaine	Une problématique ou capacité identifiable dans ce champ	Découpage du problème métier	Quel problème doit être résolu ?
Modèle métier	Une abstraction choisie pour résoudre un problème	Représentation	Quels concepts et quelles règles nous sont utiles ?
Bounded Context	Le périmètre où un modèle et son langage sont valables	Frontière de conception	Où ces concepts et ces règles gardent-ils un sens cohérent ?

Vernon distingue problem space (domaine et sous-domaines) et solution space (notamment les Bounded Contexts) dans le chapitre 2 d'Implementing Domain-Driven Design ^[V1]. Khononov formule cette distinction en expliquant que les sous-domaines sont identifiés à partir de l'activité tandis que les frontières des contextes sont conçues pour répondre aux contraintes de la solution ^{[K1, chap. 3]}.

La séparation n'interdit pas de rechercher un bon alignement entre sous-domaines et Bounded Contexts. Elle interdit simplement de présumer que les frontières sont identiques par nature.

Cette distinction n'est pas qu'une subtilité de vocabulaire. Elle permet de comprendre un choix de conception parfois contre-intuitif : plusieurs Bounded Contexts peuvent coexister pour traiter une même problématique métier.

Un sous-domaine peut nécessiter plusieurs Bounded Contexts

Ce n'est pas une anomalie intrinsèque. Un sous-domaine peut être couvert par plusieurs modèles légitimes, parce que les règles, les processus, le langage, le rythme d'évolution ou les besoins de compréhension justifient des frontières distinctes.

Nous avons ainsi choisi, pour un problème de calepinage industriel traité dans une seule application, plusieurs contextes aux modèles métier volontairement très petits, car les couches ne raisonnent pas sur les mêmes concepts : un trou de fixation, défini avec précision dans une couche, n'est représenté dans la couche supérieure qu'au travers des entraxes nécessaires à son propre calcul. Nous appelons cette approche Micro-Bounded Contexts : « micro » décrit la granularité des modèles, et non des microservices ni un nouveau pattern DDD. Ce retour d'expérience détaille ce choix et les compromis d'intégration qui l'accompagnent.

D'autres cas peuvent tenir davantage aux processus, aux responsabilités et aux rythmes d'évolution. Mathias Verraes et Rebecca Wirfs-Brock décrivent une entreprise de négoce issue d'une fusion. Le même sous-domaine Sales y est représenté par deux Sales Bounded Contexts. Les deux disposent de notions de commande et de remise ; leur signification générale reste proche, mais leurs processus de vente, règles de remise, interactions et évolutions diffèrent ^[M1].

L'enseignement est plus subtil qu'un simple « le même mot a deux sens ». Même lorsque deux équipes s'accordent globalement sur le sens d'un concept, les conditions dans lesquelles il est utilisé et doit évoluer peuvent justifier des modèles distincts.

Les auteurs rapportent également un cas volontaire de nombreux contextes dans une activité de trading, afin de laisser des modèles évoluer à des rythmes différents sans imposer une coordination permanente. Ce n'est pas une recommandation de multiplier les contextes partout : c'est la démonstration qu'un regroupement systématique n'est pas toujours économiquement ni conceptuellement supérieur ^[M1].

L'alignement 1:1 reste possible, pas obligatoire

Vaughn Vernon présente la correspondance « un sous-domaine, un Bounded Context » comme une composition souhaitable lorsqu'elle permet d'obtenir un modèle bien délimité ^{[V2, chap. 3]}. Mais il traite aussi explicitement de situations dans lesquelles plusieurs Bounded Contexts appartiennent à un même sous-domaine et de situations où les frontières des sous-domaines et des contextes se croisent ^{[V1, chap. 2]}.

Khononov précise de son côté qu'une relation 1:1 peut être pertinente, mais que d'autres stratégies de décomposition peuvent mieux répondre au problème ^{[K1, chap. 3]}. Dans un texte ultérieur consacré explicitement à cette question, Mathias Verraes rejette la prétendue obligation du 1:1 et décrit un même domaine de tarification réparti entre plusieurs modèles spécialisés, par exemple collecte de prix, apprentissage automatique, tarification manuelle et application des règles ^[M2].

Il serait donc erroné de décréter que tout sous-domaine impose exactement un contexte ; il serait tout aussi erroné de créer plusieurs contextes simplement pour multiplier les composants. La qualité du découpage dépend de la cohérence des modèles et de ses conséquences pratiques.

Et lorsqu'un contexte recouvre plusieurs sous-domaines ?

Cette configuration peut être observée, notamment dans des systèmes existants où un modèle concentre plusieurs préoccupations métier. Ce constat ne prouve pas que le regroupement soit une bonne cible.

Il faut distinguer couvrir réellement plusieurs problématiques métier et collaborer avec d'autres contextes. Par exemple, une application de vente qui consulte un tarif et déclenche un paiement ne possède pas automatiquement les modèles métier complets de la tarification et du paiement.

Un contexte qui porte lui-même des règles substantielles de plusieurs sous-domaines doit être examiné : son modèle conserve-t-il un langage cohérent ? Ses responsabilités sont-elles réellement unifiées ? Le regroupement est-il intentionnel ou hérité de l'histoire du système ? Vernon utilise notamment ce type d'analyse pour détecter des modèles trop larges dans l'existant ^{[V1, chap. 2]}.

En somme, il ne s'agit pas de découper systématiquement les sous-domaines en contextes plus petits, mais de laisser les frontières du modèle répondre à sa complexité réelle. Reste une objection fréquente : n'est-ce pas dupliquer inutilement ce qui aurait pu être mutualisé ?

Plusieurs modèles ne signifient pas duplication inutile

L'argument « un seul modèle évite la duplication » semble raisonnable lorsqu'on assimile toute répétition à une erreur de conception. Mais il faut séparer trois situations :

Deux faits métier différents. Le prix actuellement proposé à la vente et le prix convenu lors d'une commande ne sont pas deux copies interchangeables d'une même donnée. Le premier peut évoluer ; le second matérialise un engagement historique, selon les règles de vente applicables.

Deux représentations d'une réalité commune. Une même référence de produit peut apparaître dans un modèle de catalogue et dans un modèle de préparation. Les champs communs ne suffisent pas à justifier un modèle partagé.

Une règle réellement commune. Si plusieurs contextes ont besoin d'une règle dont la signification et les invariants doivent impérativement rester identiques, la reproduire indépendamment peut créer un risque de divergence. Il faut alors organiser explicitement son autorité, son partage éventuel ou sa consommation.

Ce troisième cas interdit toute caricature : le DDD ne conseille pas de copier systématiquement les règles, de multiplier les autorités contradictoires ou de synchroniser aveuglément des données.

La multiplication des modèles peut sembler contraire au principe DRY (Don't Repeat Yourself). Pourtant, DRY vise la duplication des connaissances qui devraient posséder une représentation unique faisant autorité, et non toute ressemblance structurelle entre deux modèles ^[HT1]. Mutualiser des modèles dont les responsabilités et les règles diffèrent peut ainsi introduire davantage de couplage que la duplication apparente n'en élimine. Cette tension entre DRY et orthogonalité est développée dans l'article (Too much ?) DRY.

Inversement, une classe générique et partagée de type Product ou Order peut réduire la répétition de propriétés tout en augmentant :

le nombre de consommateurs impactés par chaque évolution ;
les compromis entre usages incompatibles ;
les règles conditionnelles et les propriétés facultatives ;
la coordination requise pour faire évoluer une abstraction ;
le risque qu'une logique locale modifie le comportement attendu ailleurs.

C'est ce que Verraes et Wirfs-Brock analysent en termes de dépendance cachée et de coûts de coordination, notamment lorsque les contextes ne changent pas au même rythme ^[M1]. Fowler rappelle plus généralement les limites d'une vue unifiée des données de toute l'entreprise ^[F2].

La bonne question n'est pas : « Peut-on tout réunifier ? » Il est souvent techniquement possible de le faire.

Elle est : « Cette réunification améliore-t-elle réellement la compréhension, la cohérence et la capacité à faire évoluer le système ? »

Autonomie des modèles ne signifie pas anarchie des données

Des contextes distincts peuvent partager des identifiants, s'appuyer sur des données de référence communes, consommer les décisions d'un contexte faisant autorité ou échanger des événements et des projections.

Il convient toutefois d'éviter de confondre :

source d'autorité : qui décide qu'un fait métier est vrai et peut le modifier ;
représentation locale : ce qu'un autre contexte doit connaître pour remplir sa responsabilité ;
copie synchronisée : une stratégie technique de circulation ou de consultation des informations.

Une représentation locale peut être légitime sans devenir une seconde autorité concurrente. Et un contrat d'échange commun ne force pas deux contextes à partager leur modèle métier interne.

Le DDD dispose de patterns de relation — Context Map, Published Language, Anti-Corruption Layer, Customer/Supplier, Shared Kernel, notamment — pour rendre ces compromis explicites. Un Shared Kernel est une décision de coordination sur un périmètre limité, pas une obligation d'unifier les modèles ^{[E1, partie IV ; K2, chap. 4]}.

Une fois cette distinction clarifiée, il reste à éviter une autre confusion : des modèles séparés ne réclament pas nécessairement des services ou des déploiements séparés.

Des frontières de modèles, pas nécessairement des frontières techniques

La frontière d'un modèle et la frontière d'un composant déployable répondent à deux questions différentes. Avant d'en déduire une architecture de services, il faut donc dissiper plusieurs assimilations courantes.

Ce qu'un Bounded Context n'est pas

Un Bounded Context n'est pas, par définition :

un sous-domaine rebaptisé ;
un microservice ;
une application, un dépôt Git ou un projet .NET ;
une base de données ;
une équipe ou une case de l'organigramme ;
un simple écran, une API ou un ensemble de DTO.

Ses frontières peuvent influencer les frontières techniques et organisationnelles, mais aucune de ces correspondances n'est automatique. Un contexte peut être implémenté dans un monolithe modulaire ; son existence ne commande pas un déploiement distribué ^{[E1 ; F1 ; K1, chap. 3]}.

Pour approfondir ces possibilités de déploiement, voir Topologie des Services de Domaine.

Une nuance s'impose concernant les équipes. Un Bounded Context n'est pas une équipe, mais il devrait idéalement relever de la responsabilité d'une seule équipe, tandis qu'une équipe peut parfaitement posséder plusieurs contextes ^{[K1, chap. 3]}. Lorsque plusieurs équipes sont copropriétaires d'un même modèle métier, elles doivent coordonner leurs décisions pour en préserver la cohérence, ce qui limite leur autonomie. Une telle situation peut être héritée de l'organisation existante, mais elle constitue un signal invitant à réexaminer les frontières du modèle ou la répartition des responsabilités. La loi de Conway rappelle d'ailleurs que la structure d'un système tend à refléter les structures de communication de l'organisation qui le conçoit ^[C1].

Il nous reste alors une dernière question pratique : comment savoir si ces frontières sont bien choisies, plutôt que simplement commodes sur le papier ?

Comment reconnaître et délimiter les Bounded Contexts ?

Aucune propriété technique isolée ne suffit à reconnaître un Bounded Context. L'enquête doit porter sur le métier et sur les contraintes de conception.

Quelques questions aident à éprouver un découpage :

Langage — Les mêmes mots désignent-ils des choses différentes ? Inversement, des mots distincts décrivent-ils le même concept ?
Règles et invariants — Les conditions de validité et les transitions métier diffèrent-elles réellement ?
Finalités — Les modèles permettent-ils de résoudre des problèmes différents, même à partir des mêmes faits ?
Évolution — Les changements ont-ils des causes, des acteurs et des rythmes différents ? Les mutualiser impose-t-il une coordination injustifiée ?
Autorité — Qui porte chaque décision métier ? Une frontière mal placée crée-t-elle plusieurs autorités contradictoires ?
Intégration — Les contrats et traductions nécessaires entre modèles sont-ils explicites et soutenables ?
Propriété — Une seule équipe peut-elle porter ce modèle et décider de ses évolutions ? Si le découpage envisagé oblige plusieurs équipes à modifier le même modèle, la frontière est probablement mal placée, ou l'organisation est à revoir.
Coût global — Le bénéfice de la séparation compense-t-il les coûts supplémentaires de compréhension, d'intégration et d'exploitation ?

Les signaux contraires sont tout aussi importants. Deux équipes, deux API, deux écrans, deux bases de données ou deux canaux commerciaux ne constituent pas, à eux seuls, une preuve qu'il faut deux Bounded Contexts.

Le coût de coordination évité à l'intérieur des contextes ne doit pas simplement être déplacé, sans bénéfice, vers leurs échanges. Les frontières sont des hypothèses de conception à éprouver et à réviser à mesure que la compréhension du domaine progresse.

Ces questions ne se règlent pas en chambre. Plusieurs pratiques aident à les instruire avec les experts métier. L'EventStorming ^[B1] fait apparaître les changements de vocabulaire et les événements pivots, là où se dessinent souvent les frontières. Le Bounded Context Canvas ^[DC1] oblige à expliciter, pour chaque contexte candidat, sa finalité, son langage, ses décisions et ses dépendances. La Context Map ^{[E1, partie IV]} rend visibles les relations et les traductions entre contextes.

La délimitation ne se déduit ni du nom d'un sous-domaine ni du nombre de canaux ou de systèmes : elle se confronte aux scénarios, aux règles, au vocabulaire, aux responsabilités et aux changements réels.

Dans notre exemple fictif de grande distribution, supposons que les commandes drive et en livraison à domicile partagent langage, règles et équipe responsable : un modèle commun suffit. En revanche, si la commande traiteur est validée par un acompte, interdit les substitutions et obéit à des délais d'annulation fixés par les magasins, ces différences de règles et d'autorité justifient un modèle et un Bounded Context distincts, au sein du même sous-domaine supposé de prise de commande.

Cette démarche permet de distinguer trois travaux :

Comprendre le métier et identifier les sous-domaines.
Concevoir les modèles nécessaires et les limites de leur validité.
Choisir l'implémentation technique et les mécanismes d'intégration.

Le troisième travail est important ; il ne doit pas se substituer aux deux premiers.

Conclusion

Ce qui distingue domaine, sous-domaine et Bounded Context

Le domaine est le champ métier étudié ; ses sous-domaines correspondent aux problématiques qu'on y identifie. Un modèle métier en retient les concepts, règles et comportements utiles à un problème, tandis qu'un Bounded Context délimite le périmètre où ce modèle et son langage restent cohérents.

Ces découpages ne se confondent pas. Un sous-domaine peut nécessiter plusieurs Bounded Contexts, sans que plusieurs usages, équipes ou composants suffisent à eux seuls à justifier cette séparation. Et plusieurs modèles peuvent représenter une même réalité sans imposer un modèle universel ni autoriser des vérités métier contradictoires.

L'objectif n'est donc ni de tout mutualiser ni de multiplier les contextes, mais de préserver des modèles compréhensibles, cohérents et capables d'évoluer.

Nous découvrons les problèmes métier ; nous concevons les frontières des modèles qui permettent de les résoudre.

Sources et ancrages bibliographiques

Les références ci-dessous rassemblent des ouvrages et articles de référence sur le DDD, la modélisation et leurs enjeux sociotechniques. Les formulations du document sont des synthèses et interprétations, sauf indication explicite de citation ; les exemples routiers et de grande distribution sont des illustrations originales.

[E1] Eric Evans. Domain-Driven Design Reference: Definitions and Pattern Summaries. Domain Language, édition 2015. Voir « Definitions », p. vi ; « Bounded Context », p. 2 ; « Ubiquitous Language », p. 3 ; partie IV, « Context Mapping for Strategic Design ». Texte original officiel, PDF librement accessible. La référence synthétise des patterns issus de Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003/2004).

[V1] Vaughn Vernon. Implementing Domain-Driven Design. Addison-Wesley, 2013, chapitre 2, « Domains, Subdomains, and Bounded Contexts », en particulier « Real-World Domains and Subdomains » et « Making Sense of Bounded Contexts ». Chapitre chez l'éditeur / O'Reilly. Ce chapitre présente l'opposition problem space / solution space, l'alignement souhaitable entre sous-domaines et contextes et les cas où leurs frontières ne coïncident pas.

[V2] Vaughn Vernon. Domain-Driven Design Distilled. Addison-Wesley, 2016, chapitre 3, « Strategic Design with Subdomains ». Chapitre chez O'Reilly. Vernon y présente l'alignement 1:1 comme une composition optimale dans l'exemple étudié, et non comme une identité de définition entre les deux notions.

[K1] Vlad Khononov. Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O'Reilly, 2021/2022, chapitre 3, « Managing Domain Complexity », en particulier « Bounded Contexts Versus Subdomains » et « The Interplay Between Subdomains and Bounded Contexts ». Chapitre chez O'Reilly. Référence pour la distinction entre sous-domaines découverts et frontières de modèles conçues, ainsi que pour l'analogie des cartes.

[K2] Vlad Khononov. Learning Domain-Driven Design, chapitres 1 « Analyzing Business Domains » et 4 « Integrating Bounded Contexts ». Chapitre 1 ; chapitre 4. Référence pour la classification des sous-domaines et les relations d'intégration.

[M1] Mathias Verraes et Rebecca Wirfs-Brock. « Splitting a Domain Across Multiple Bounded Contexts », 14 juin 2021. Source primaire particulièrement directe sur le même sous-domaine représenté par plusieurs Bounded Contexts, avec exemples de la fusion de deux entreprises de négoce et de l'activité de trading, et discussion des coûts de coordination et des vitesses d'évolution.

[M2] Mathias Verraes. « No, Your Domains and Bounded Contexts Don’t Map 1 on 1 », 28 août 2025 (mise à jour du 2 septembre 2025). Clarification directe sur les frontières de modèle comme décisions de design, les cas de décomposition volontaire d'un domaine et les raisons techniques, organisationnelles et évolutives de ne pas imposer le 1:1. Le billet rapporte également un commentaire ultérieur d'Eric Evans.

[F1] Martin Fowler. « Bounded Context », 15 janvier 2014. Pour le rapport entre modèle cohérent, langage commun et représentations divergentes de concepts partagés.

[F2] Martin Fowler. « Data Guide — Scoping Data ». Pour la remise en question du modèle de données unique à l'échelle de l'entreprise.

[HT1] Andrew Hunt et David Thomas. The Pragmatic Programmer: 20th Anniversary Edition. Addison-Wesley, 2019, section « DRY—The Evils of Duplication ». Extrait officiel consacré à DRY. Source primaire pour la distinction entre duplication de connaissance et simple répétition de code.

[B1] Alberto Brandolini. Introducing EventStorming: An Act of Deliberate Collective Learning. Leanpub, ouvrage en cours d'écriture. Page de l'ouvrage. Pour la découverte collaborative du domaine et des frontières par les changements de langage.

[C1] Melvin E. Conway. « How Do Committees Invent? », Datamation, vol. 14, n° 4, avril 1968, p. 28–31. Article original. Source primaire de la loi de Conway, sur le lien entre les structures de communication d'une organisation et les systèmes qu'elle conçoit.

[DC1] DDD Crew. Bounded Context Canvas. Grille collaborative pour expliciter la finalité, le langage, les décisions et les dépendances d'un contexte candidat.