L'architecture hexagonale : vision produit ou pattern technique ?

"On fait un hexagone pour le front et un autre pour le back". J'ai été très surpris la 1ère fois où j'ai entendu cette idée. Pas pour les hexagones -je pratique l'architecture hexagonale depuis longtemps- mais par leur nombre. Pourquoi deux hexagones ?

En creusant le sujet, je pense que tout le monde ne met pas la même chose derrière ces hexagones.

Dans l'article originel d'Alistair Cockburn, le cœur de l'hexagone est appelé Application. La motivation de l'architecture hexagonale est de pouvoir facilement piloter cette application, ce qui est utile pour la tester ou pour créer de nouveaux cas d'usage. Mais l'application est vue comme un tout. On ne parle pas de la découper en plusieurs hexagones.

Bien sûr, cela n'empêche pas, dans de nombreux cas, d'avoir 2 applications qui dialoguent. Par exemple, une application serveur offrant une API réseau publique et une application cliente qui fait des appels à cette API.
Chacune de ces deux applications a son propre hexagone. Chacune a aussi un adaptateur pour implémenter la communication réseau.

Ces deux applications vivent leur vie indépendamment. Par exemple, lorsque le serveur fait évoluer son API, il garde une compatibilité ascendante pour les clients qui seraient toujours sur une ancienne version de l'API. Un corollaire est que les adaptateurs vivent aussi leur vie indépendamment : l'évolution de l'API du serveur n'impose pas une évolution de l'adaptateur du client.

Pour le dire autrement, chacune de ces deux applications est un produit. Chacune a son propre backlog. Ces deux applications peuvent être développées par la même organisation mais elles peuvent aussi être développées par des organisations différentes.

Envisageons maintenant une application où, d'un point de vue produit, on n'a pas de notion de client/serveur. Il y a juste des fonctionnalités dont la responsabilité est distribuée entre du code qui tourne dans un navigateur web et du code qui tourne dans le cloud.

On peut être tenté de définir un hexagone front et un hexagone back. Le problème est que ces hexagones vont être dépendants l'un de l'autre.

Quand le produit va évoluer, on aura des cas où une même fonctionnalité impactera le code des deux hexagones, voire le code des adaptateurs qui permet leur communication.

On a une illusion du découplage.

Ce n'est peut être pas intuitif au premier abord mais, pour tirer le meilleur parti de l'architecture hexagonale, il faut y intégrer la vision produit car elle seule peut être garante du découplage.

Dans le cas de notre application où les parties client et serveur sont le même produit, l'idéal est de n'avoir qu'un seul hexagone. Oui, je sais, ça va pas être simple si les deux parties sont sur des solutions techniques différentes, notamment sur le langage utilisé. Ce sujet mériterait un billet à part entière.