Domain-Driven Design - février 2008

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 :