Sous-domaines
VoletStratégique La page qui détermine où l’effort de modélisation est rentable — et où il est du gaspillage.
Problème et solution
La distinction la plus clarifiante de tout DDD, et celle qu’on saute le plus souvent :
| Nature | Verbe | |
|---|---|---|
| Domaine et sous-domaines | L’espace du problème — ce que fait l’entreprise | On les découvre |
| Contextes délimités | L’espace de la solution — comment on décide de le modéliser | On les conçoit |
Le domaine, c’est l’activité de l’entreprise : la vente de billets, le transport de colis, la gestion de sinistres. Il existe indépendamment de tout logiciel, et il ne se négocie pas. Les sous-domaines sont ses parties distinctes : la tarification, l’expédition, la comptabilité, l’authentification des utilisateurs. Ils ne sont pas non plus un choix — ils sont là, on les constate.
Ce qui relève du choix, ce sont les contextes délimités qu’on construit pour y répondre. Confondre les deux conduit à débattre de découpage technique alors que la question est de savoir de quoi l’entreprise s’occupe.
Trois natures de sous-domaines
Tous les sous-domaines ne se valent pas, et les traiter à égalité est l’erreur de dosage la plus coûteuse en DDD.
| Cœur de métier | Support | Génerique | |
|---|---|---|---|
| Définition | Ce qui distingue l’entreprise de ses concurrents | Nécessaire et spécifique, mais sans avantage | Problème déjà résolu partout |
| Complexité | Élevée, et croissante | Faible à moyenne | Élevée, mais pas la vôtre |
| Change | Souvent | Rarement | Presque jamais |
| Décision | Construire, avec les meilleurs | Construire simplement | Acheter ou intégrer |
| Technique | Patrons tactiques DDD | CRUD assumé, couches | Bibliothèque, SaaS |
| Exemples | Moteur de tarification, allocation de tournées | Référentiel de contrats types, back-office | Authentification, envoi de courriels, facturation TVA, PDF |
Trois conséquences pratiques en découlent, et chacune se traduit en décision.
Le tactique ne s’applique qu’au cœur. Agrégats, objets valeur, événements de domaine : ce sont des outils chers en fichiers et en discipline. Sur le cœur, ils sont rentables parce que les règles y sont nombreuses et changent. Sur un sous-domaine de support, ils produisent trois couches d’abstraction pour un formulaire de saisie.
On n’écrit pas un sous-domaine génerique. Écrire son propre système d’authentification, son propre moteur de calcul de TVA ou son propre générateur de PDF, c’est dépenser des mois sur un problème où aucun client ne remarquera votre excellence. Les sous-domaines génériques sont complexes — c’est ce qui les rend tentants — mais leur complexité est celle de quelqu’un d’autre.
Les meilleures personnes vont sur le cœur. C’est contre-intuitif, parce que le sous-domaine génerique est souvent le plus intéressant techniquement. Un ingénieur brillant préférera réécrire le moteur de recherche que modéliser des règles de remise. C’est exactement l’inverse de ce qu’il faut.
Warning
Le cœur de métier n’est pas « la partie techniquement la plus difficile ». C’est la partie qui fait gagner de l’argent ou qui donne l’avantage. Chez un transporteur, l’optimisation de tournées est le cœur et le suivi de colis est du support ; chez un site de vente en ligne, le suivi de colis peut être le cœur si c’est là que se joue la satisfaction client. Même industrie, cœurs différents.
Comment identifier le cœur
Quatre questions, dans cet ordre, posées au métier et non à l’équipe technique.
- Qu’est-ce qu’un concurrent devrait reproduire pour vous prendre vos clients ? La réponse est presque toujours le cœur.
- Où l’argent se fait-il — ou où les pertes se font-elles ?
- De quoi la direction parle-t-elle en réunion stratégique ? Le sujet qui revient est rarement l’authentification.
- Qu’est-ce que vous n’accepteriez jamais de sous-traiter ?
Un signal complémentaire, très fiable : le cœur est la zone où les experts ne sont pas d’accord entre eux. Un sous-domaine où tout le monde répond la même chose sans hésiter est un sous-domaine simple ; celui où deux experts débattent d’un cas limite est celui qui contient la valeur — et le risque.
Un exemple
Pour une plateforme de billetterie de spectacles :
| Sous-domaine | Nature | Décision |
|---|---|---|
| Placement et allocation de sièges | Cœur | Modèle riche, agrégats, meilleurs profils. C’est là que se joue le remplissage des salles. |
| Tarification dynamique et quotas | Cœur | Idem. Les règles changent chaque saison. |
| Catalogue des spectacles et des salles | Support | CRUD assumé, une interface d’administration correcte suffit. |
| Contrôle d’accès aux salles | Support | Spécifique, mais les règles sont stables. |
| Paiement | Génerique | Prestataire. Écrire un moteur de paiement serait absurde. |
| Comptes utilisateurs, authentification | Génerique | Fournisseur d’identité. |
| Édition de factures et TVA | Génerique | Bibliothèque ou service. |
| Envoi de courriels et de notifications | Génerique | Prestataire. |
L’exercice a une valeur qui dépasse la technique : il rend visible que sur huit sous-domaines, deux justifient l’investissement de modélisation. Sur beaucoup de projets, on découvre à ce moment-là que l’équipe a passé l’essentiel de son énergie ailleurs.
Note
La nature d’un sous-domaine se déplace avec le temps. Un cœur finit par se banaliser quand la concurrence l’a rattrapé — il devient du support. Un sous-domaine génerique peut devenir un cœur si l’entreprise décide d’en faire un avantage : la logistique était du support chez la plupart des distributeurs avant de devenir l’arme d’Amazon. La classification est à refaire périodiquement, pas une fois pour toutes.
Le rapport aux contextes délimités
Dans l’idéal, un sous-domaine correspond à un contexte délimité. Dans la réalité, la correspondance est rarement parfaite, et ce n’est pas un défaut :
- Un sous-domaine, plusieurs contextes — un cœur volumineux peut être découpé en plusieurs modèles pour rester compréhensible par une équipe.
- Plusieurs sous-domaines, un contexte — deux sous-domaines de support modestes cohabitent souvent sans dommage dans un même modèle.
- Un contexte hérité qui en traverse plusieurs — le progiciel existant qui couvre à la fois la facturation, le stock et les achats. C’est un fait, pas une cible ; il se traite sur la cartographie de contextes.
La règle utile : les sous-domaines cadrent l’investissement, les contextes cadrent le modèle. On se sert des premiers pour décider où mettre l’effort, des seconds pour décider où mettre les frontières.
Références
- Eric Evans, Domain-Driven Design, chapitre 15 — Distillation
- Vlad Khononov, Learning Domain-Driven Design, chapitre 1 — la meilleure exposition de la distinction cœur / support / génerique
- https://github.com/ddd-crew/core-domain-charts — canevas pour positionner ses sous-domaines