Le chapitre sur la programmation objet a posé l'idée, le code gagne
à parler le langage du métier. Le Domain Driven Design, ou DDD, est la méthode qui pousse cette idée jusqu'au
bout. Elle a été formalisée par Eric Evans dans un livre de 2003 que la profession appelle simplement "le livre
bleu".
Sa thèse tient en une phrase. La difficulté d'un logiciel de gestion n'est presque jamais technique, elle est de
comprendre le métier. L'architecture du code doit donc épouser le métier, et pas l'inverse. Le reste de ce
chapitre te donne les trois notions que tu entendras le plus souvent quand une équipe s'en réclame.
Le langage ubiquitaire
C'est le point de départ. Développeurs et équipes métier se mettent d'accord sur un vocabulaire unique, et ce
vocabulaire se retrouve tel quel dans le code, dans les tests, dans les tickets et dans les réunions. Si le
métier dit "avoir de la marge", aucune classe ne s'appellera ProfitCalculator.
Ça paraît anodin, c'est la partie la plus difficile. Une équipe métier utilise son vocabulaire depuis des
années et n'a aucune envie de le disséquer. Lui expliquer qu'elle emploie deux mots pour la même chose, ou le
même mot pour deux choses, passe rarement pour une priorité. Pourtant chaque approximation laissée en place
finit en bug ou en fonctionnalité à refaire.
Exemple :
La boutique parle de "commandes", l'entrepôt parle d'"expéditions". On croit d'abord que c'est le même objet vu de deux fenêtres. Puis un client commande trois articles dont un est en rupture. L'entrepôt envoie les deux disponibles aujourd'hui et le troisième la semaine suivante. Une commande, deux expéditions. Le jour où le support veut afficher "le" numéro de suivi d'une commande, la question n'a tout simplement pas de réponse, et il est un peu tard pour s'en apercevoir.
Le chapitre sur la programmation objet citait déjà le duo "produit" et "offre", que des entreprises entières emploient comme des synonymes. C'est exactement le même mécanisme, et ça se termine toujours pareil, par des chiffres qui ne tombent jamais juste et des développements refaits deux fois.
Les contextes délimités
Deuxième idée forte, et sans doute la plus utile. Plutôt que de chercher un modèle unique et parfait qui
conviendrait à toute l'entreprise, le DDD assume que chaque service a sa propre vision, valable chez lui
uniquement. C'est ce qu'on appelle un contexte délimité (bounded context).
Prends le mot "produit" dans une entreprise qui vend des vélos. Pour le catalogue, c'est un titre, des photos,
une description et un prix. Pour l'entrepôt, c'est un poids, un volume, un emplacement dans une allée et une
quantité restante. Pour le service après-vente, c'est une durée de garantie et un historique de réparations.
Trois modèles du même mot, et aucun n'a besoin des informations des deux autres. On construit donc trois briques
logicielles distinctes, chacune avec son vocabulaire, plutôt qu'un objet unique à quarante champs que plus
personne n'ose toucher.
Le travail consiste alors à définir la frontière entre elles et ce qui la traverse. Quand une brique doit
consommer les données d'une autre (ou pire, celles d'un logiciel externe qu'on ne maîtrise pas), on intercale
une couche de traduction qui convertit le vocabulaire étranger vers le sien. Ça évite qu'un modèle mal fichu ne
contamine tout le reste.
Tu retrouveras cette notion de frontière beaucoup plus loin, quand nous parlerons de
microservices. Découper une application en services indépendants sans
avoir d'abord identifié ces contextes est la meilleure façon de se retrouver avec les mêmes problèmes qu'avant,
en plus dispersés.
Les agrégats
Troisième notion que tu entendras. Un agrégat, c'est un groupe d'objets qu'on manipule toujours ensemble, avec
une porte d'entrée unique.
Une commande et ses lignes de commande forment un agrégat. On ne modifie jamais une ligne dans son coin, on
passe par la commande, qui reste responsable de sa propre cohérence. C'est elle qui garantit qu'on n'ajoute pas
une ligne à une commande déjà expédiée, ou que le total correspond bien à la somme des lignes.
L'intérêt est très concret. Les règles métier vivent à un seul endroit, celui qui a toutes les informations pour
les appliquer. Sans ça, elles se retrouvent recopiées dans chaque écran qui touche à une commande, et il y en a
toujours un qu'on oublie.
Ce que ça change pour toi
Si ton équipe fait du DDD, tu vas le sentir avant même de connaître le mot.
- Plus de réunions de cadrage : les développeurs poseront des questions de vocabulaire qui te sembleront pointilleuses. Elles ne le sont pas.
- Un vocabulaire qui se fige : une fois un terme choisi, il est utilisé partout, y compris dans les interfaces. Changer un mot devient un vrai sujet.
- Des périmètres plus nets : "ça, c'est la facturation, pas le catalogue" devient une réponse courante, et c'est plutôt bon signe.
Le DDD a un coût réel, en temps de modélisation comme en complexité de code. Sur un site vitrine, un outil interne ou un prototype qu'on jettera dans six mois, c'est de la sur-ingénierie caractérisée. Il prend son sens sur les domaines vraiment compliqués, la facturation, la logistique, l'assurance, la santé, là où les règles métier sont plus difficiles que la technique.
Ce qui reste vrai partout, même sans appliquer la méthode, c'est le premier principe. Prends le temps de nommer les choses avec ton équipe technique, une bonne fois, ensemble. Aucune quantité de code ne rattrape un accord qui n'a jamais été passé.