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)…
