Chapitre 5.10Le Domain Driven Design

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.

La méthode a deux moitiés. La première, dite stratégique, s'occupe du vocabulaire, des frontières entre les domaines et de l'endroit où investir. Elle concerne tout le monde, et surtout toi. La seconde, dite tactique, est l'outillage que les développeurs utilisent pour traduire ça en code. Ce chapitre insiste sur la première, et n'emprunte à la seconde qu'une notion, celle que tu entendras le plus.

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.

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.

Ce langage commun n'est pas qu'un principe, c'est un livrable. Un glossaire écrit, tenu à jour, où chaque terme a une définition et un seul, et qu'on peut opposer en réunion quand deux services se disputent un mot. C'est probablement la contribution la plus utile qu'un profil produit puisse apporter à un projet technique, et elle ne demande aucune compétence en code.

L'atelier devant le mur de post-it

Tu seras un jour convoqué à un atelier de trois heures, devant un mur couvert de post-it orange, pour dérouler avec l'équipe technique tout ce qui se passe entre "le client ajoute un article" et "le colis est livré". Cet atelier porte le nom d'event storming, et il sert précisément à faire émerger le vocabulaire et les frontières dont parle ce chapitre.

Ce qu'on attend de toi y est simple et précieux. Tu es la source du savoir métier, pas un spectateur. Tu corriges les mots, tu signales les cas particuliers que personne n'a prévus, le client qui commande depuis deux pays, le retour partiel, le bon d'achat qui expire pendant la livraison. Chaque cas oublié à l'atelier coûte dix fois plus cher découvert en production. Les schémas qui en sortent sont ceux du chapitre sur la modélisation.

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. C'est exactement le pattern Adapter du chapitre sur les design patterns, appliqué à la frontière entre deux métiers.

Où investir, le domaine coeur

Tous ces contextes ne se valent pas, et le DDD le dit clairement. Il y a le domaine coeur, ce qui fait la différence de l'entreprise face à ses concurrents, et il y a le reste, la facturation, l'envoi d'emails, la gestion des comptes, que tout le monde fait pareil.

Le coeur mérite du sur-mesure, les meilleurs développeurs et le temps de modélisation décrit ici. Le reste s'achète sur étagère ou se branche sur un service tiers, sans état d'âme. Décider où passe cette frontière est une décision de direction exprimée en vocabulaire technique, et c'est sans doute la plus rentable de tout le chapitre.

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.

Deux autres sigles voyagent souvent dans les mêmes réunions, CQRS et event sourcing. Le premier sépare le code qui modifie les données de celui qui les lit, le second stocke l'historique complet des événements plutôt que l'état actuel. Ce sont des choix techniques distincts, qu'on peut faire avec ou sans DDD, et qui ont un coût de complexité important. Une équipe qui les cite comme allant de soi mérite qu'on lui demande quel problème ils règlent ici.

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é.