Fabien Bézagu

Dur titre de billet. J'ai récemment commencé ma deuxième lecture de DDD ^[1] et je constate avec une pointe d'amerture que notre tentative de modéliser le domaine sur lequel s'appuie notre application est loin de correspondre à une approche DDD :-(

Bien que le code que nous avons écrit reprend quelques termes métiers, nous avons été obligé d'introduire des notions que les experts du domaine et les utilisateurs ne s'attendraient absolument pas à trouver ici. Pire, nous passons souvent beaucoup de temps à relire ce code en nous posant des questions interdites : mais à quoi ça sert et comment ça marche ? Le code devrait être le reflet de notre modèle. Nous devrions pouvoir dialoguer en toute transparence avec les experts sur les mécanismes internes non techniques de ce code. Ce n'est pas le cas. Ce code n'est le reflet d'aucun modèle cohérent et exprimable.

Bien sûr, je peux nous trouver des tonnes d'excuses : certes nous n'avons jamais rencontré les utilisateurs ni les détenteurs du besoin; certes nous n'avons vu notre "expert du domaine" qu'environ trois ou quatre fois en six mois; certes le processus de développement est anti-agile avec un modèle en cascade d'un pouvoir destructeur sur l'information essentielle tel que j'en ai rarement connu. Mais ce ne sont que des excuses.

Plus nous sommes entourés de personnes qui nous retranscrivent un besoin dépouillé de sa substance fonctionnelle, plus nous pêchons par orgueil en prétendant mieux connaître le métier que l'utilisateur lui-même. Cet orgueil nous aveugle sur nos propres faiblesses.

Ce projet est ma deuxième tentative de modèliser un domaine avec toute sa complexité et sa richesse. La première fois également, je n'avais pas accès aux experts du domaine. A quoi sert de modéliser un domaine correctement si on ne peut pas s'en servir pour communiquer avec les personnes qui connaissent le métier et qui ont besoin de nous pour répondre à un besoin ? Certainement à peu de chose. C'est d'ailleurs un des prérequis qu'impose Eric Evans : pouvoir dialoguer avec un expert du domaine. Je comprend aujourd'hui toute la force de ce prérequis: au delà du bête recueil des besoins, il s'agit de mettre en place une osmose totale entre les développeurs et les experts du domaine.

Sur mon projet actuel, comme je l'ai déjà dit, nous n'avons pas pu mettre en place ce dialogue "osmotique". Je reste convaincu que l'approche DDD est bonne même dans ce cadre (maintenabilité, gestion de la complexité, testabilité...) mais nous aurions dû être d'avantage schizophrène que nous l'avons été.

Dorénavant, je serai plus vigilant et une chose est sûr : la prochaine fois, je ferai mieux.