Note 3 ; Quand implémentation rime avec confusion.

C’est un beau pavé de presque 600 pages que nous a produit l’auteur. J’avais pas mal d’espoirs sur celui-ci, en effet malgré l’ampleur du mouvement DDD suscité par Eric Evans, j’ai toujours eu pas mal de difficultés avec le niveau stratosphérique de son propos. Avec ce volume orienté implémentation, je pensais régler ce problème. Nous n’y sommes pas et il s’en faut de beaucoup. Certes il y a du code, quoique souvent avec des « leaky abstractions » : pourquoi donc le choix de la stratégie de persistance devrait-il influer le modèle du domaine ? On arrive au pire avec les « values object » où l’on dit à demi-mot qu’il s’agit d’un choix technique ! L’étude de cas n’aide malheureusement pas beaucoup : elle manque de vie, son propos est trop abstrait et bien que le choix du sujet soit très pertinent pour moi, j’ai eu toutes les difficultés à le suivre. J’oublie encore les interludes « cow-boy logic » sensés donner de la légèreté au texte, mais incompréhensibles pour les non-américains.

Le premier chapitre est en quelque sorte le « business case » du DDD. On n’y apprends pas grand chose mais au moins le texte est compréhensible ainsi que les extraits de code. Tout de même, 42 pages pour cela… C’est d’ailleurs la taille du second chapitre « domain, sub-domain & bounded-context ». Les 3 niveaux de structuration rendent le propos difficile à suivre et à mon avis d’une complexité non-nécessaire. De plus l’exemple choisi (identity & access control) n’est guère pertinent. Il en résulte que l’on sort du chapitre avec peu d’éléments pour déterminer la granularité du bounded context mais avec un gros mal de tête sur les notions avancées.

Le chapitre 3, context map est un court interlude qui évoque la projection d’un bounded context sur un autre. C’est intéressant sans être mortel. Polluer le propos avec du http ou du rest est non seulement inutile mais hors de propos. Malheureusement, c’est récurrent dans tout le livre. Contrastant avec cela, le chapitre 4 « architecture », c’est du sérieux avec ses 56 pages ! On y évoque différents types architecturaux comme le modèle en couche et l’architecture hexagonale d’Alistair Cockburn. Il évoque aussi le DIP qui n’est jamais que la même intention que l’Adapteur au centre de l’architecture hexagonale, ce qui ne semble pas effleurer l’auteur. Le CQRS est à peu près compréhensible, ce qui n’est pas le cas de l’Event-driven architecture, bien qu’il faille concéder une représentation intéressante intégrant l’architecture hexagonale. Le pipe and filter est juste évoqué et les « sagas » c’est à dire les transactions applicatives sont plus à décoder qu’à lire. L’Event-sourcing et les data frabric ont aussi doit à quelques mots. Dans l’ensemble le chapitre est bien trop long pour son contenu ?

Le chapitre 5 traite des entités. Un concept central en DDD et 45 pages couvrent ce sujet. Il commence par un long morceau sur la génération d’identités (avec des bidules techniques hors de propos que je vous passe. Une idée à laquelle je m’oppose avec la dernière énergie : si une entité peut être affublée d’un identifiant technique (ce qui n’est pas du ressort du DDD), il doit y exister une identification métier. L’auteur a complètement raté cela. Je suis plus d’accord sur la discussion à propos de la prédominance du comportement sur les propriétés, les exemples de code étant toutefois assez pauvres. Le chapitre 6 sur les values object est lui en très grande partie un beau ratage. J’évacue tout de suite le propos sur la persistance qui n’a pas sa place dans ce texte. L’auteur rate la nature même du value object, disons à 50% et laisse même penser que le choix entre entité et value object peut être arbitraire. Rappelons quand même qu’un value object n’a pas d’identifiant métier et que c’est son contexte d’usage qui lui confère un sens. Vous venez d’économiser 45 pages.

Je suis d’un avis mitigé sur les services décrits au chapitre 7. Ils me font penser à la manière dont JEE a perverti le modèle objet. Toutefois l’auteur défends bien son cas et met en garde comme il le faut. Le chapitre n’occupe pas plus de place qu’il n’en faut avec ses 20 pages et on n’est pas loin du sans faute. Dommage que ce soit sur un sujet aussi marginal. Les « domaine vents » couverts au chapitre 8 procurent un élément intéressant, qui le serait resté si l’auteur ne nous avait pas asséné dans la foulée les questions de services de messaging, d’architecture Rest et leur influence sur la gestion des évènements. Car bien entendu, le sous-système technique doit influencer le modèle du domaine ? Je ne parle même pas de la section dévolue à la persistance, c’est en quelque sorte le « running joke » du livre.

Le chapitre 9 est un nouvel interlude d’une quinzaine de pages sur les « modules ». Un concept qui s’ajoute aux domain, sub-domain et bounded-context. J’aurais aussi bien vécu sans cela. Les agrégats traités au chapitre 10 sont un autre poids lourd du DDD. L’auteur fait du bon boulot pour nous aider à déterminer ce qu’est un agrégat et nous donner des règles de granularité. Viennent au-dessus de cela des étrangetés comme la référence entre agrégats par identifiant, un dogmatisme bien peu étayé. Les considérations techniques liées aux performances et à l’empreinte mémoire donnent plus de confusion que d’aide. Par contre la partie consacrée aux transactions est nettement plus digne d’intérêt.

Le chapitre 11 est un nouvel interlude. Il concerne les factories, oui on parle bien du Design Pattern ! Passons. Le chapitre 12 est consacré aux repositories. Les différents styles décrits par l’auteur sont réellement intéressants. J’aurais aimé que l’auteur développe les usages avec leur pros / cons et peut-être quelques diagrammes de séquence pour illustrer cela. A la place nous avons beaucoup de texte et une masse d’implémentation que je considère comme étant du mauvais côté de la barrière.

D’après l’auteur, on n’a pas vraiment parlé technique jusqu’ici. La technique c’est le sujet du chapitre 13 « integrating bounded context » et l’auteur se lâche. C’est pénible à lire, truffé de http, Json, Rest et autres protocol buffer. C’est la fête sur 55 pages et c’est sans intérêt. Le livre se referme presque sur le chapitre 14 « applications ». le gros de la troupe concerne le passage d’information entre couche IHM et domain model, l’occasion pour l’auteur de pousser ses propres patterns.
En sus, le texte nous propose en annexe un chapitre orienté Event-sourcing qui n’est pas écrit par l’auteur et illustre son propos en C# (les exemples du livre sont en Java). Globalement bon et bien illustré, il fait le tour des différentes questions sur l’agrégation d’évènements sur le modèle du domaine.

Vous l’aurez compris, j’ai été très déçu. Tout comme cette note de lecture, le propos est très verbeux, confus même là ou de bons diagrammes auraient clarifiés pas mal de chose. Orienter le DDD est une chose et une bonne chose pour clarifier le propos, mais hélas les adhérences techniques sont bien trop présentes et affaiblissent terriblement le texte en plus d’être inutiles. Reste un certains nombre de points sur lesquels l’auteur ne m’a pas convaincu et où je ne suis pas d’accord. Je crains que sa fibre technique lui ait fait rater des choses.

Référence complète : Implementing Domain-Driven Design – Vaughn Vernon – Addison Wesley / DDD series 2014 – ISBN : 978 0 321 83457 7