Interlude — Modéliser le domaine pour ne pas coder des malentendus
Pourquoi ce chapitre existe
Les régressions métier ne viennent pas toujours d'une règle oubliée. Elles viennent souvent d'un même mot utilisé pour désigner plusieurs réalités : « client », « actif », « annulé », « validé », « disponible ». Le code peut alors être cohérent localement tout en reliant des concepts qui ne devraient pas l'être. La modélisation de domaine donne une forme explicite à ce langage, à ses règles et à ses frontières.
Les idées essentielles
- Un modèle de domaine est une représentation volontairement limitée d'une réalité métier, conçue pour guider une décision et un comportement.
- Un langage partagé réduit les traductions implicites entre produit, support, données et code.
- Le même mot peut avoir des sens légitimes différents selon la frontière ; forcer une définition universelle crée souvent du couplage.
- Les exemples, invariants et transitions sont plus utiles qu'un diagramme d'entités isolé.
Partir des décisions, pas des tables
Une table customer peut servir à l'identité, la facturation, le support et le marketing. Elle ne dit pas quel concept décide d'une remise, qui peut modifier une adresse de facturation ni à quel moment un compte devient inactif. La modélisation commence donc par les décisions et les événements qui importent : un abonnement est-il renouvelable ? une commande est-elle remboursable ? une personne peut-elle administrer cette organisation ?
Un atelier de domaine bien conduit collecte des exemples concrets, y compris les contre-exemples et cas de transition. Il fait émerger les termes ambigus et les questions non résolues. Son résultat ne doit pas être une vérité théorique : il doit rendre le prochain changement plus compréhensible et fournir les mots des tests, contrats et métriques.
| Terme vague | Question de clarification | Modèle plus utile |
|---|---|---|
| Client actif | Actif pour quel service, à quelle date ? | Éligibilité à une capacité donnée |
| Commande annulée | Paiement, expédition et facture sont-ils aussi annulés ? | Transitions distinctes et invariants associés |
| Solde | Est-ce une valeur calculée, disponible ou comptable ? | Source, date d'effet et mode de calcul explicites |
Respecter les frontières de sens
Le domaine Paiement peut parler de capture et remboursement ; le domaine Abonnement de renouvellement et droit d'accès. Une tentative de créer un état unique qui satisfait les deux tend à accumuler des valeurs hybrides et des exceptions. Il est souvent préférable d'avoir deux modèles reliés par un contrat explicite : chacun reste cohérent dans son contexte et traduit ce qui est nécessaire pour l'autre.
Un exemple comme « un abonnement annulé après facturation conserve son accès jusqu'à la fin de la période » peut devenir un test de décision, un scénario produit et une phrase de documentation. Lorsqu'un terme change de sens, les exemples qui l'emploient rendent l'impact visible immédiatement.
Anti-patterns
Utiliser le schéma de base comme modèle de domaine
Le stockage optimise la persistance, la recherche ou l'historique. Il ne doit pas imposer les concepts de travail aux équipes. Exposer directement ses colonnes encourage les lecteurs à dépendre de décisions qui ne leur appartiennent pas.
Chercher un langage parfaitement universel
L'unification forcée masque les différences de responsabilité. Le but est que chaque frontière soit précise sur son vocabulaire et que les traductions entre frontières soient conscientes, pas que toute l'entreprise utilise chaque mot de la même manière.
Formaliser sans confronter aux cas réels
Un glossaire qui ne change ni les discussions, ni les tests, ni les contrats devient un décor. Les modèles doivent être révisés lorsqu'un incident, une exception support ou une nouvelle capacité contredit leur simplicité initiale.
Bonnes pratiques
Tenir un glossaire décisionnel court
Documenter les termes qui portent des règles, leurs définitions contextuelles, exemples et propriétaires. Supprimer les définitions décoratives. Le glossaire devient ainsi un outil de revue et d'onboarding, plutôt qu'une encyclopédie figée.
Faire du modèle un instrument de découverte
Lorsqu'une demande ne s'exprime qu'en solution — « ajouter ce champ » — revenir aux événements, acteurs, invariants et transitions révèle souvent un problème mieux posé. Le modèle est utile précisément parce qu'il peut être modifié quand l'équipe apprend.
Checklist — Le modèle réduit-il une ambiguïté réelle ?
- Quelle décision ou quel invariant ce concept aide-t-il à clarifier ?
- Les termes importants ont-ils des exemples, contre-exemples et transitions ?
- Une frontière de sens distingue-t-elle des usages qui évoluent différemment ?
- Le modèle apparaît-il dans les tests, contrats et conversations de produit ?
- Quelle donnée ou quel comportement ne doit pas être confondu avec ce concept ?
- Quel événement ou incident justifierait de réviser ce modèle ?
À retenir
Modéliser le domaine n'est pas dessiner un système idéal. C'est rendre les décisions métier assez précises pour que produit et ingénierie puissent les implémenter, les tester et les faire évoluer sans coder des traductions contradictoires.