Architecture hexagonale vs. functional core

Pas envie de long discours, cette semaine. Du code, juste du code.

Du blabla, j'en avais fait un peu quand-même, il y a quelques mois, au sujet du pattern functional core / imperative shell (f❤️, pour simplifier). Je vous mets le lien ici ⬇️

https://blog.mathieueveillard.com/functional-core-imperative-shell/

A partir de là, je sais que mes lecteurs les plus fidèles ne me lisent plus. Papa, Maman, merci quand-même, je vous aime 😘

Comparons à présent les architectures hexagonale et f❤️ au travers de l'exemple ci-dessus. Que remarquons-nous, au-delà d'une mise en situation fonctionnelle des plus captivantes ?

Nous remarquons que la version hexagonale "contient" la version f❤️. Autrement dit, on pourrait tout à fait refactorer le domaine de la version hexagonale pour qu'il fasse appel au domaine de la version f❤️.

La différence est là : dans l'architecture hexagonale, les requêtes en lecture et écriture sont faites par le domaine, qui n'est donc a priori pas pur. Tandis que dans l'architecture f❤️, elles sont faites par l'API. De ce fait, le domaine peut être pur, et la convention veut qu'il le soit.

Alors que faire au quotidien ?

Mon conseil serait de commencer par une architecture f❤️, parce qu'elle est plus simple au premier abord… en espérant que ça tienne.

En espérant que ça tienne ? Oui, car un domaine faisant peu de traitements et beaucoup de coordination risque de vous poser problème : si telle donnée présente en base a telle valeur, alors je peux faire mon calcul, tandis que si elle a telle autre valeur, alors je dois aller chercher une seconde donnée en base etc. L'architecture hexagonale vous permet de gérer cela avec facilité, le f❤️ demande de faire appel à des outils plus sophistiqués.

Je l'évoquais sans rentrer dans le détail dans mon premier article, la programmation fonctionnelle a recours aux monades pour pallier ce problème. Seulement, cela demande un apprentissage qui ne se fait pas en quelques jours. Pour vous, qui devez faire en sorte que des développeurs juniors puissent contribuer à la codebase, autant éviter de mettre de telles barrières à l'entrée.

En pareille situation, vous pouvez tout à fait basculer sur une architecture hexagonale, qui vous offrira un pragmatisme bienvenu tout en conservant la qualité essentielle de ces deux architectures : isoler le domaine, faire en sorte qu'il ne dépende de rien.

Voilà, il n'y a pas forcément beaucoup plus à dire sur le sujet. Pour résumer :

• Commencez par une architecture f❤️ / imperative shell
• Si nécessaire, basculez sur une architecture hexagonale.