Le blog de L'ami S'ami

Les retours et réactions suite au dernier Symposium ont été nombreux. Certains m’ont également fait part de leurs impressions par mail. J’avais promis de donner quelques explications sur l’aspect logistique et les quelques difficultés de la matinée. Je répondrais ensuite au duo Fabien/BodySplash sur ma session DDD.

Logistique générale et cas particulier de la session DDD

La session DDD est décidément celle qui fait le plus couler de pixels. Pour rappel, cette session que j’animais avait lieu à 11h juste après la session plénière. Très vite en arrivant sur les lieues le matin, nous nous sommes rendus compte avec François Merand côté MS que l’organisation des TechDays avait buggué en attribuant une salle de 120 places. Pour rappel, les 3 derniers Symposium ont eu une affluence variant de 300 à 700 personnes. Il était difficile d’imaginer qu’autant de fidèles aient rendu les armes sous les assauts marketing de la machine TechDays. Lorsque la salle s'est remplit en 3mn après la session plénière nous avons compris qu’une partie importante du public allait devoir être refoulée par l’hôtesse d’accueil. A cet instant, plus d’une trentaine de personnes se tenaient debout ou assis à même le sol pendant que quelques VIP trustaient les premiers rangs.

Bien entendu on pourra toujours arguer qu’il est préférable d’avoir une salle pleine à craquer et refuser du monde plutôt qu’une salle à moitié vide. Pour le pédagogue que je suis, refouler ne serait-ce qu’une personne est quelque chose de difficilement concevable, vous l’entendrez sûrement au ton un peu irrité lors de la publication des webcasts. Après coup, la session DDD a dû refuser entre 60 et 100 personnes. Croyez-moi, j’en suis sincèrement désolé.

Il y aussi ceux qui m’ont fait le reproche d’avoir noyé la marque du Symposium dans celle des TechDays. Il est vrai que la session DDD n’apparaissait pas en tant que session étiquetée Symposium et qu’il a fallu constamment changer de salle tout au long de la journée. On ne peut que le regretter mais s’associer à la logistique des TechDays était aussi l’opportunité de toucher un public plus large que les habituels fidèles. A noter que Microsoft m’a gentiment proposé de rejouer la DDD plus tard dans la semaine. Une proposition que j’ai du décliner faute de vol, en période de grève.

Sur le reste de la journée, l’ensemble des sessions étaient pleines sans avoir jamais eu (à ma connaissance) à fermer de portes.

Concernant enfin les sujets traités lors de la journée, vos retours me confortent dans l’idée qu’ils étaient pertinents. C’est finalement là le plus important. Ce Symposium a aussi permit de faire découvrir de nouvelles têtes, comme celle d’Aurelien avec la session ROA.

Session DDD et billets de Fabien/BodySplash

Pour revenir maintenant à des considérations plus techniques et sûrement moins sensibles que l’organisation du Symposium, j’ai promis de répondre aux critiques constructives formulées par le duo Fabien/BodySplash sur le contenu de la session DDD. C’est un peu long mais le sujet vaut la peine d’être débattu.

Pour avoir lu les billets en question et les avoir publié sur DNG, si j’y réponds c’est que je trouve les remarques argumentées même si le terme « flop » me semble disons, un peu inadapté (pour rester courtois :-)).

La discussion qui suit préfigure d’une certaine manière de l’ambiance générale qui règne autour du sujet DDD et des problématiques (techniques) que cette approche aura à gérer dans les semaines à venir.

Cela fait environ 4 ans que je suis de près l’approche DDD, depuis la sortie du Evans finalement. Je dois dire que la première fois que j’ai lu ce livre, j’ai sursauté au plafond en me disant « jamais je ne conseillerais à quiconque de mettre en œuvre ce genre de choses ». Et de fil en aiguille, quelques années plus tard j’avoue avoir un peu changé d’avis en m’apercevant qu’Evans avait vu juste sur un certain nombre de points. Le domaine deviendrait un élément central d’une application fortement couplée (je ne parle pas de SOA ou d’urbanisation qui se situe à un niveau plus haut) et l’ubiquitous langage, un allié de poids pour la formalisation du besoin MOE/MOA.

Lorsque les temples communautaires (que ce soit Java ou .NET) ont commencé à inviter en 2007 les adeptes du DDD pour parler du sujet, j’ai compris qu’une nouvelle tendance s’amorçait. Il se trouvait que cette communauté partageait aussi un certain nombre de valeurs avec les communautés dites « agiles », le refactoring, le TDD mais aussi le mapping O/R.

Parler DDD au Symposium me paraissait du coup inéluctable tant la communauté Francophone dans ce domaine était inexistante.
De l’avis de tous, les deux seuls ouvrages sur DDD publiés à ce jour en 5 ans sont d’une complexité effroyable même pour un expert du domaine. J’avoue avoir relu 3 fois l’Evans et quasiment autant de fois le Nilsson en .NET. Je n’ai jamais entendu deux personnes évoquer le sujet de la même manière. Et pour cause, le DDD laisse trop de place à la subjectivité. Et je ne parle pas des multiples néologismes créés parfois de toute pièce par Evans pour introduire des termes tels que les agrégats, les repositories, les value object ou les factories. Des notions qui ont bien entendu un sens très précis dans la philosophie DDD mais autant de sens technique utilisé à tord et à travers.

Du coup, soit je traitais le sujet DDD à la mode pure Evans, soit je donnais ma vision du DDD (celle qui me semble la plus pragmatique) pour tenter de convaincre le maximum de personnes qu’il y avait tout de même des choses pertinentes dans le DDD. Charge ensuite à chacun d’y aller en fonction de sa sensibilité ou de s’arrêter en posant ses limites. J’ai préféré la seconde option car elle correspondait mieux à ma vision du DDD.

J’ai passé des années à lutter contre le syndrome du DTO et de ce que j’appelle la mode des entités de services. Cette approche, que je considère aujourd’hui comme « vieille école » consiste à créer des objets métier type Facture, Commandes, Client et à y insérer le maximum de code technique. Lorsque 80% de ce code est de type infrastructure, pour être précis, des accès en base, les problèmes techniques surviennent très vite. Par définition mais aussi il est vrai par conviction, je considère qu’une entité ne doit pas être associée à une quelconque API Technique, ce fût le sujet de ma dernière session Symposium en 2005 et je n’en démordrais pas. Lorsqu'une entité de service ne peut être véhiculée sur la couche de présentation, le développeur la copie généralement dans un ValueObject.

Par ailleurs, nous sommes nombreux dans la communauté à penser que le DDD se trompe en voulant à tout prix s’appuyer sur des Repositories. Le premier à avoir traité ce problème est Christian Bauer, co-créateur d’Hibernate avec son fameux billet : « Repository Pattern vs. Transparent Persistence ». Il explique très concrètement, exemple à l’appui que le domaine doit rester « clean ». I think this pattern is a step backwards and should not be recommended. Keep the domain model implementation clean, testable, and reusable: no security checks, transaction demarcation, or explicit data store access in any of these classes. C’est aussi mon avis. Gavin King son collistier, enfonce le clou dans ce billet (Still Confused about Repositories) : Do we /really/ need another stupid layer in our already horribly over-engineered Java applications?. La réponse donnée par Fabio Kung montre à quel point subsiste cette forme d'hypocrisie dans le DDD qui consiste à ne pas appeler un chat un chat. Il illustre une DAO d’un côté et un Repository de l’autre. Jugez-en par vous-même, seul le nom de la classe change et conclut par « But err… what’s the difference? Just the name? YES! But the names are important, right?”. Les noms sont peut-être importants, mais pas au point de créer une nouvelle couche. Cet exemple montre à lui seul le paradoxe de cette couche du domaine qui s’appuie sur des DAO, pardon des repositories pour récupérer des données mais refuse l'appellation DAO.

Je ne parle même pas des problèmes d’Eager ou Lazy Fetching qu’engendre cette démarche qui se résume souvent par « qui peut le plus peut le moins ». Cette proximité Domaine/DAO empêche de véhiculer une entité de manière sérialisée sur le poste client et ouvre la porte au syndrome du DTO Evil. Les Repository renvoient des collections d’entités ou des agrégats et la combinaison des stratégies de fetching (je récupère un client et ses lignes, un client sans ses lignes, un client et ses factures, etc...) aboutissent inéluctablement à du N+1 Select puisqu'aucun service ne précharge au préalable les données. J'ai cherché très longtemps une sorte de "sample" ou de "PetShop" DDD, la seule application disponible sur domaindrivendesign.org est un convertisseur de monnaie. Pas très "business case".

Le contexte de ma présentation et mes griefs à l’encontre du DDD étant posées, je peux quoter les critiques formulées par Fabien et Body Splash.

Commençons par BodySplash :
« Critiquer une conférence de Sami Jaber est un exercice périlleux ». Quelle idée ! La critique constructive est souvent rare, il ne faut pas s'en priver.

« Du coup, à se concentrer sur la technique, l'ami Sami passe à côté de l'intérêt de DDD, et en plus se mélange les pinceaux dans les concepts. »

Après le contexte que je viens de poser, on comprendra aisément que laisser de côté la technique dans toute architecture ne peut-être que voué à l’échec.

« Il existe en fait 3 types de service définit par Evans: les services d'application (interface, export excel), les services d'infrastructure (envoi de mail) et les services du domaine qui répondent à un métier bien précis (transfert d'argent entre deux comptes par exemple) ».

Cet exemple a été donné par les deux blogs. Effectivement, c’est ce que Evans dit et c’est aussi ce que je regrette. Lorsqu’on souhaite envoyer un mail, il faut être dans la couche d’infrastructure. En revanche, pour faire un export Excel, il faut être dans la couche services d’application. Très honnêtement, comment peut-on imaginer une seconde définir des couches d’architecture avec des exemples aussi légers (le Nilsson reprend d'ailleurs exactement les mêmes exemples). Comment fait-on lorsqu’on souhaite envoyer un mail contenant un export Excel ?

Une couche ne se définit par seulement par des cas fonctionnels, mais aussi par des dépendances binaires, une architecture physique et logique, un couplage par interface. L’export Excel est-il côté client ou côté domaine ? Est-il transactionnel ? Il existe des dizaines de cas où cette approche atteint ces limites. Je revendique donc l’explication donnée pour la couche de service vu sa totale subjectivité.

« Si on en croit Sami Jaber, tout ce qui est sous une racine d'agrégat est une value object. Faux. »
Les webcast seront publiées en Mars de mémoire, il m’est difficile de répondre à des choses que je n’ai pas dites. Le slide 15 montre les objets Customer et Order comme des entités avec une identité (la composition, donc les VO concernent les objets de l’agrégat)

« Une autre confusion est de comparer les repositories aux DAL ». Je pense avoir suffisamment démontré qu’à part le nom de la classe, on peut qualifier le Repository d’entrepôt, ça n’en fait pas autre chose qu’une DAO.

« Dans une deuxième moitié de session, Sami Jaber a présenté une manière intéressante de tenter d'automatiser le binding entre les objets du modèle et la couche présentation. L'idée est de placer des attributs par exemple sur nos setter des objets du modèle, et on peut imaginer un framework de présentation capable de lire par réflexion ces attributs pour automatiquement générer les validateurs qui vont bien ».
Pourquoi systématiquement recopier côté IHM ce qui existe déjà côté Entité. Bindons nos entités, c’est peut-être anti-DDD Evans like, mais largement plus pragmatique que faire de la réflection et du DTO à tout va.

« il n'existe pas de simple application CRUD ».
Peut-être pas « simples », mais pas si complexes, sûrement. Une application peut avoir du métier sans que cela justifie d’empiler des couches à tord et à travers. On en a assez souffert ces cinq dernières années.

Pour finir et faire écho à Fabien :
« 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 ».
Fabien, j’adhère sincèrement au fondements pragmatiques du DDD et la place centrale que le domaine doit jouer dans les applications de demain. Mais je rejette les délires d’architectes en mal de couches qui ont plombé tant de projets ces dernières années. Dans la même lignée que Gavin King et Christian Bauer qui l’expliquent d’ailleurs très bien.

« Ce langage n'est pas, comme il le dit, un jargon spécifique du projet ».
Même remarque que précédemment cf Page 11 de mon slideshare, il est bien précisé que c'est un langage technique entre MOA/MOE.

« 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 ».
Lorsqu’une entité répond à un besoin de présentation, on l’utilise. Lorsqu’une entité ne répond pas au visuel d’une IHM, on utilise un Value Object contrairement à une démarche systématique qui consiste à cloner à tout va des grappes d’objets. Sur une application de gestion « traditionnelle », plus de 80% des écrans peuvent bindés sur des entités. Sans sacrifier le Design, le gain en termes de productivité est énorme. Lorsqu'on essaie de forcer le DDD dans sa forme la plus extrème contre les réalités projets, on arrive aux échecs que tu cites toi même dans ce billet.

Pour finir le débat, Fabien et BodySplash, je comprends votre déception par rapport au fait que je n’ai pas soutenu DDD sans réserve dans cette session. Mais "ne pas soutenir" ne signifie pas "ne pas comprendre" ou "sortir des énormités". Avec cette réponse, j’imagine que le contexte est plus clair. Si ce n’est pas le cas, je vous invite tous les deux, à rédiger un article que je publierais avec grand plaisir sur DNG pour continuer le débat. Steve Degosserie, qui a assisté à la session m’a proposé de traiter le sujet de manière plus poussée dans un futur article. N’hésitez pas à en faire de même.

Sami