DDD reboot: Alistair in the ‘hexagone’
Le dernier meetup DDD Reboot accueillait une star : Alistair Cockburn (AC), inventeur du terme Hexagonal Architecture. Voici mes impressions :
1. Impression
1.1 La prez
La prez a tenu ses promesses, puisque DDD reboot a pour but de faire découvrir et adopter le DDD : de ce que j’ai entendu le feedback était très bon chez ceux qui ont découvert le concept d’archi hexagonale. C’est le plus important à long terme.
Les seuls mitigés connaissaient déjà le sujet : sur le coup ça fait toujours râler quand on finit tard et que 95% n’allait pas plus profondément que ce qu’on connaissait déjà. AC (Alistair Cockburn) n’a quasi pas montré de nouveau concept/technique ninja/”deeper insight” (mais il faisait aussi la prez pour la première fois).
1.2 Le meetup
Peut-être que ce côté râleur (sur le moment) est aussi dû au fait que post-prez, les 1664 chaudes (par 30°) n’ont pas produit le même Zen clément et magnanime que des Westmalle Tripel fraîches servies en verre calice.
Mais, c’est quand même une occasion de croiser beaucoup de connaissances ! Forte affluence, sûrement en grande partie pour voir AC ce coup-ci. On ne va pas se plaindre que le DDD attire du monde, par ce temps-là, il faut vraiment être motivé.
Aussi, c’est une occasion “dédiée” de penser au DDD. On re-pense plus tard aux idées qui nous ont intéressé, mais le déclencheur est d’avoir participé à l’événement.
Les organisateurs ont l’air d’en avoir bavé avec les locaux prêtés… ils s’en sont bien tirés dans des circonstances pas idéales (chaleur, projo, ..).
2. Idées intéressantes découvertes :
2.1 Rechercher en particulier les design patterns de Gerald Mezzaro, décrits comme chiadés.
2.2 Nommage “configurable dependency” du concept plus abstrait implémenté par le DI.
2.3 J’avais oublié la notation des mocks/fakes de repos avec la flèche qui sort et re-rentre dans l’hexagone. C’est très visuel pour montrer que l’implem est interne à l’appli, mais que ce n’est qu’un détail d’implémentation sélectionné au runtime par configuration :
2.4 Dans le cas d’une archi CQRS, penser à un hexagone pour le write model mais pas forcément pour le read model ! Point à creuser.
3. Points de divergence
3.1 Je préfère splitter le layer domain de Thomas en layers (domain, application) et son infrastructure en (infrastructure, exposition). Dans les schémas de AC, infra serait à droite et exposition à gauche, et application à l’extérieur de domain :
– Ça donne un découpage en types de tests très naturel : domain=unit, appli=acceptance/bdd (cucumber), infra=intégration, exposition=test d’api (spring mock mvc) :
– Aussi dans mon expérience (domain, appli, infra, expo) limite plus que (domain, infra) les risques de grosse erreur de design.
J’ai cru comprendre que AC partirait plutôt sur (domain, infra, expo), alors que Thomas partirait initialement sur (domain, infra).
3.2 J’ai l’impression que le appli de Thomas dépend de l’infra ? Je préfère que comme domain, appli ne dépende pas de infra puisque c’est de la logique métier, même si use-case-specific (point de vue plus spécifiquement DDD que hexagonal architecture).
Ce point me gêne beaucoup, car dans mon cycle je commence par des tests BDD de appli, et à ce stade je ne me pose pas de question d’infra. Le BDD sur appli est la première étape du développement d’une feature, là où on s’assure seulement d’un compréhension partagée de la feature et d’un vocabulaire commun entre devs/métiers:
D’ailleurs le test vérifiait à la fois la logique métier et les implem des ports, ça mélange les préoccupations (tests should_xxx_with_yyy_port_impl).
Je me demande si ce désaccord n’est pas une question de définition : le choix montré a l’air de correspondre à la définition “hexagonal architecture” de application, plutôt qu’à la définition DDD.
3.3 Souvent le BC expose uniquement une API REST.
Donc, les tests les plus externes du BC devraient être des tests d’API (layer exposition).
Dans un live coding, le choix d’une exposition par console est logique (pour minimiser la technicité), mais ça fait moins apparaître l’intérêt d’un layer exposition distinct de infra que le cas (plus réaliste) d’une API REST, et ça n’était pas mentionné.
4. Agaçant (mais pardonné)
– La 1664 chaude (et tout ça après le teasing de AC..) grrrrrrrrrrrr
– Le retard technique au début : projo king-size, mais qui marche pas.
5. Autre : sur le pourquoi de hexagone et pas pentagone
– En dehors du fait que le pentagone soit trop dur à dessiner, le carré trop banal, etc… Je ne sais pas si ça vient de là, mais les seuls “pavages du plan” avec des polygones réguliers sont avec des triangles/carrés/hexagones : pas avec des pentagones.
Quand on fait du context mapping, c’est comme si on pavait le plan (SI) avec les hexagones (BCs)…
Salut Laurent, Je te confirme que la prez était calibrée pour faire connaître le pattern a ceux qui n’en avait jamais fait ou qui avaient bien galéré avec.
Merci pour ton compte-rendu, je vais tâcher ici de répondre à ou de compléter certains de tes points « mitigés ».
Ma séparation en 2 parties uniquement (Domain et Infra) est motivée par un soucis de simplicité. Plus on rajoute de split (comme tu le propose entre exposition et infrastructure), plus cela complique la solution et risque de distraire les nouveaux arrivants sur le projet. J’ai tellement vu de solution avec 80% de complexité accidentelle (genre 8 projets / couches techniques) et très peu de Domaine (1 seul projet « Domain » avec des pauvres data classes anémiées et un gros transaction script) au final, que je préfère désormais forcer le trait et pousser les gens à ne pas en faire trop « du côté de l’infra » pour que tout le monde se concentre sur le Domain.
De la même manière, je ne comprends pas la séparation que tout le monde fait ou suggère entre « application” et « domain » (une observation qui revient tout le temps). A part sur 1 seul projet vécu où on a voulu avoir un “shared kernel » (au passage: très mauvaise idée dans notre contexte 😉 , je n’ai jamais vu de « Domain » réutilisable entre plusieurs applications (et qui aurait pu justifier cette séparation donc). C’est sans doute parce que je faisais des services (vs. library oriented architecture), mais le « Domain » pour moi a toujours été au service des usages, et donc très directement lié à une application/un service (et encapsulé dedans). C’est pour cela que je n’ai jamais trouvé cette séparation très pertinente.
Pour le dire autrement, j’ai plus souvent souffert de l’erreur de design : « on a trop de projets/couches techniques pour pas grand chose » que d’être bloqué parce qu’on n’avait pas séparé assez notre domain logic… -> d’où mon choix personnel. Mon obsession pour le YAGNI y est peut-être aussi pour quelque chose 😉
« L’appli/le service » chez moi n’est qu’une coquille technique qui instancie l’hexagone dans un Composition Root et qui ne manipule/référence ensuite dans ses contrôleurs (ASP.NET MVC par exemple) que les adapteurs de gauches (ceux pour rentrer dans l’hexagone). Dans le cas d’une API REST, son code sera limité à mon framework REST préféré qui appelle l’adapteur de gauche dans une callback de ressource/verbe HTTP et qui réponds ensuite à ses clients HTTP en fonction de ce que l’adaptateur de gauche lui aura rendu comme résultat. C’est pour cela que cette coquille a besoin de référencer le projet d’Infra (pour les adaptateurs) et le projet du domaine (pour accéder aux différents ports dont ont besoin l’hexagone et les adaptateurs).
Je confirme que le live-coding a été orienté « soyons didactiques sur l’architecture hexagonale » plus que DDD-style (j’aurai fait quelque peu différemment sinon).
Désolé pour la bière; je te confirme n’avoir moi aussi eu que des bières chaudes ce soir là ;-P
Thomas
Salut Thomas, merci pour ta réponse détaillée.
Je suis bien d’accord sur la philosophie YAGNI, venant du monde Java tu imagines que moi aussi j’ai vu mon lot d’abstractions nuisibles 🙂
Malgré tout, peut-être que je pourrais te convaincre en te montrant mon walking skeleton. J’en finalise un anonymisé, donc ça sera possible incessamment.
Pour la bière, si vous venez chez Zenika, vous serez bien reçus! On est très forts là-dessus. (wink wink)