Idée principale

Une exception nommée ElementAnnuléNonModifiable n'est pas un message d'erreur : c'est une règle de gestion écrite en code, lisible par un agent de support qui ne programme pas. Une exception nommée InvalidStateException dit la même chose au processeur et rien à personne d'autre. C'est cet écart, et non la qualité technique du dépôt, qui décide si une question produit peut y trouver sa réponse.

La condition se décline sur toute la matière : des entités qui portent les noms employés par les utilisateurs, des actions dont l'intitulé se lit, des événements qui racontent ce qui s'est passé, des politiques qui rendent visibles les réactions en cascade, des modules dont la structure est prévisible. Un dépôt où les concepts du domaine sont cachés derrière des noms techniques et où les règles sont dispersées reste opaque, quel que soit le soin apporté à son découpage ou à sa couverture de tests.

L'exigence est ancienne — les approches de conception pilotées par le domaine la portent depuis longtemps — et elle n'a pas été créée par l'arrivée des assistants. Un développeur qui reprend un tel dépôt paie la même traduction permanente entre le besoin métier et la mécanique logicielle ; chaque évolution demande de reconstruire ce lien, chaque recherche de règle coûte plus cher. Ce que change la possibilité d'interroger le code, c'est que ce défaut devient mesurable de l'extérieur de l'équipe technique : il ne se traduit plus en lenteur diffuse, mais en réponses que personne ne peut obtenir.

Pourquoi c'est important

Cela déplace le critère qu'on applique avant d'installer un dispositif d'interrogation. La question à poser à un dépôt n'est pas « est-il bien tenu ? » mais « le vocabulaire du domaine y est-il écrit ? » — deux propriétés qui se rencontrent souvent ensemble et n'ont pas de lien nécessaire.

Cela donne aussi un argument non technique à un investissement qui n'en avait qu'un. Renommer des concepts vers le langage du métier cesse d'être une préférence d'artisan dès lors que le support, l'avant-vente et le product management en dépendent pour obtenir des réponses.

Nuances et limites

L'uniformité n'existe pas : un même dépôt parle métier dans le module facturation, écrit vingt ans plus tôt par des gens qui connaissaient le domaine, et reste muet dans la couche d'intégration. La condition se vérifie zone par zone, pas sur le dépôt entier.

Le vocabulaire inscrit dans le code est par ailleurs daté. Un nom d'entité qui a survécu à trois repositionnements raconte un métier qu'on ne pratique plus, et sa lisibilité même le rend trompeur.

Enfin, un nom métier juste peut recouvrir une règle fausse. Qu'une exception exprime une règle rend celle-ci lisible, pas exacte : ce qui devient interrogeable est le code, pas le produit voulu.

Questions ouvertes

• Qui arbitre le vocabulaire quand les utilisateurs appellent un objet autrement que le code, et que les deux usages ont leurs porteurs dans l'entreprise ?
• À quoi se mesure, avant d'engager le travail, l'écart entre le vocabulaire d'un dépôt et celui du domaine ?