Fabien Bézagu

Je vais essayer de décrire dans ce billet ce que je crois être un pattern. Il s'agit peut-être d'une fausse bonne idée ou le pattern existe peut-être déjà. Dans tous les cas, les retours seront grandement appréciés.

Lire la suite

Lors de la session d'ouverture, Sami Jaber nous a présenté Domain Driven Design (DDD). J'attendais cette session avec impatience car, comme mon lecteur assidu le sait, je fais tout mon possible pour mettre en avant cette approche au quotidien.

J'ai toujours admiré le travail et la qualité d'orateur de Sami. Lors du Symposium DNG 2005, j'avais trouvé sa présentation brillante et je l'avais senti passionné et convaincant. Mon sentiment est plutôt à l'opposé par rapport à sa session d'hier.

Je sais que c'est très prétentieux de ma part mais je pense qu'il est passé complètement à côté de ce sujet et je vais essayer d'expliquer pourquoi je pense cela.

• Une nouvelle architecture ? : il a voulu présenté DDD comme une nouvelle architecture d'application : ce n'est pas le cas. DDD est une approche, pas une énième façon de mettre les couches les unes sur les autres. Bien sûr, il est important de séparer ces couches mais le point important de DDD est d'avoir une couche séparée contenant tout le modèle du domaine.

• Les services : je crois qu'il s'agit de sa plus grosse erreur. Pour lui, le principe de DDD consiste juste à inverser la couche du domaine qui s'appuierait désormais sur les services. Non, non et non. Selon Evans, il existe trois types de services : les services d'application (interface avec l'utilisateur, export des fichiers...), les services du domaine (ceux qui répondent à un vrai problème métier : transfert de fonds bancaires...) et les services d'infrastructure (envoie de mail, communication réseau...). Ces trois types de services appartiennent chacun à leurs couches respectives : application, domaine et infrastructure. Les services du domaine ne doivent pas être mis en retrait ou en avant des entités et des objets valeur mais bien à côté, sans les séparer. Je crois que c'est ce genre d'erreur qui produit une question pertinente d'un auditeur à la fin : Mais le métier, il est dispersé partout ?!. C'est exactement le contraire que prône Eric Evans : recentrer le métier dans le modèle et communiquer avec l'expert du domaine sur ce cœur.

• Les repositories : là encore, comparer les repositories à des DAO est une erreur. Comme je l'esquissais déjà dans un précédent billet, la différence est plus profonde : les repositories doivent être vues comme des collections d'entités et pas comme des simples objets d'accès aux données. La persistance doit être considérée comme une incidence du cycle de vie des entités dépassant celui de la session utilisateur.

Au delà de ce que Sami a dit, c'est surtout ce qu'il n'a pas dit qui me gêne. Je sens bien qu'il n'adhère pas du tout à DDD (C'est pas moi qui le dit, c'est Eric Evans) et on perçoit une certaine pointe de fatalisme dans l'approche DDD (Je n'y adhère pas forcément mais je vous en parle car dans cinq ans vous aurez à faire face à cette approche). Il n'a pas, à mon humble avis, saisi la force de DDD qui réside dans cette volonté de "presser la connaissance" (crunching knowledge) pour en retirer un langage commun (ubiquitous language) qui va dès lors qu'il a été mis en évidence être utilisé conjointement par les développeurs et les experts du domaine pour réaliser le modèle. Ce langage n'est pas, comme il le dit, un jargon spécifique du projet mais bel et bien le langage métier qui permet enfin d'éviter les problèmes de traduction et d'incompréhension des deux mondes que sont la MOE et la MOA.

Dans une deuxième moitié de sa présentation, il a également voulu présenter une façon de binder les entités du modèle à l'interface utilisateur. L'approche est louable et j'avoue qu'il est séduisant de descendre les contraintes de validation au niveau du modèle. Je pense que cette idée va dans le bon sens. Cependant, le binding n'est pas la réponse à tout et il n'a pas évoqué possibilité de mettre en place un framework MVC pour faire la glue qu'il lui manque entre son IHM et le modèle. Dommage. Les entités du modèle ne sont pas forcément exposées aussi brutalement à une couche de présentation; la mise en place d'un couche applicative est parfois indispensable, ce qui, dans une approche du "tout bindé" est infaisable.

Ma conclusion est la suivante : si vous voulez réellement vous intéresser à DDD, suivez les liens suivants.

• www.DomainDrivenDesign.org, site de référence. Les livres intéressants sont présentés dans la section Book.
• Livre DDD Quickly dont Sami a parlé
• Groupe de discussion créé par Eric Evans sur Yahoo

Petit message personnel : Sami, si jamais tu passes par ce coin pommé du web, je tiens à m'excuser pour cette critique virulente que je souhaite constructive et t'invite à me laisser un petit commentaire.

Edit du 13/02/08 : Voici quelques retours sur la session :

• Compte-rendu par InsideIT
• Retour de Philippe PEURET

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.

Lorsqu'on crée une architecture basée sur le Domain Model, il semble courant d'utiliser des classes nommées XxxDao ou YyyRepository. Qu'on les appelle avec l'un ou l'autre terme, elles ont toujours plus ou moins la même interface, à savoir :

public interface IXxxDaoOrRepository
{
  IList <Xxx> GetAll();
  Xxx GetById(int);
  void Add(Xxx);
...
}

Un exemple d'utilisation basé sur le terme DAO est l'article (à lire) de Billy McCafferty.

Dans son livre ADDDP^[1], Jimmy Nilsson utilise quant à lui le terme Repository.

Partant du principe selon lequel deux termes différents ont des significations différentes, je me suis récemment posé la question suivante : à part le goût personnel, quelles sont les différences entre le terme Repository et l'acronyme DAO ? Voici mon sentiment...

Selon moi, un DAO ressemble à une couche ou à un filtre permettant d'accéder aux données. Lorsqu'un client utilise un DAO, il aura alors l'impression que son appel sera relayé à une autre entité (base de données, fichier xml, autre couche, etc...).

Lorsque j'essaie de visualiser une Repository (un entrepôt en français), je ne vois plus une couche plate mais plutôt une boîte, un conteneur qui se suffit à lui-même ou du moins qui masque complètement les secrets de son implémentation.

Même si je comprend qu'on puisse préférer le terme DAO, il est clair que, dans mon approche actuel, ma préférence va vers le terme Repository qui me semble plus dans l'esprit du DDD.

Edit du 16/02/08 : plus d'un an après avoir écrit ce billet, je me rend compte que, même si j'avais "senti" la différence entre ces deux concepts que sont la DAO et la Repository, je ne voyais qu'une différence de nommage. Aujourd'hui, et notamment après la lecture DDD et à la lumière de mon expérience, je comprend pourquoi j'avais raison de penser que c'était différent et la raison principale est la suivante : la Repository est un concept du modèle du domaine, pas la DAO.

Voici le livre de Jimmy Nilsson que je suis en train de lire en ce moment. Lorsque j'avais lu PoEAA ^[1], j'étais à la fois ébloui mais aussi un peu resté sur ma faim. Ebloui car les patterns qui y étaient présentés me permettaient de mettre un nom sur de nombreuses constructions que j'avais utilisées jusqu'à présent. Je pouvais aussi améliorer la qualité de mes architectures en asseyant ma confiance sur ces patterns. J'étais cependant resté sur ma faim car je ne voyais pas nettement comment appréhender un projet basé sur le Domain Model, le plus éblouissant des patterns à mes yeux. C'est dire comme j'attendais ce livre qui se proposait de mettre en oeuvre, par des exemples concrets (et en C#), ce pattern. Le fait que NHibernate soit au sommaire rajoute encore à son attrait.

Pour l'instant aux trois-quarts du livre, je dois dire que je ne suis pas déçu ! Jimmy Nilsson nous prend par la main et nous emmène là où son expérience l'a conduit : centrer toute son attention sur le Domain Model.

Un plaisir en entrainant un autre, il utilise une méthode de Test-Driven Development (TDD). J'avais déjà vu NUnit mais je me rends compte désormais que la question fondamentale n'était pas dans le comment tester mais bien quoi et quand ! La méthode TDD me plaît et je vais essayer de la mettre en oeuvre désormais.

Je reviendrai donc plus tard sur ce livre et essaierai de discuter sur certains détails.

Pour plus d'infos

Site de Jimmy Nilsson : http://www.jnsk.se/