Architecture hexagonale : de deux maux il faut choisir le moindre
L’architecture hexagonale, pour isoler le domaine
Sur le papier, l’architecture hexagonale est le paradis du développeur.
À raison, car elle permet d’écrire le code du domaine et le code applicatif en faisant abstraction des contingences matérielles, c’est-à-dire l’infrastructure : bases de données, APIs tierces etc. On va droit au but, au cœur du métier, on implémente en isolation et en Test-Driven Development un ensemble cohérent de règles de gestion et l’on apporte très vite de la valeur.
Point de magie ici mais quelques patterns bien maîtrisés :
-
L’inversion de dépendances, et l’injection de ces dernières au lancement de l’application ;
-
Un adapter, qui adapte la dépendance réelle à l’interface définie par le domaine.
Pour nous, développeurs, c’est le paradis 🌞🏝️🌈 Chacun sa version du paradis, je vous l’accorde.
À l’aide, mon domaine fuit !
Sauf qu’au moment de mettre tout cela en œuvre, il est fréquent d’éprouver une vague insatisfaction. En creusant un peu, on finit par mettre des mots dessus :
Mais il y a du domaine en dehors du cœur hexagonal ! Mon domaine fuit !
Et mauvaise nouvelle : c’est normal.
Qu’entend-on par là ? Si mon domaine change, mon adapter doit changer également, puisque c’est une couche d’adaptation au domaine. C’est bien la preuve qu’il y a un peu de connaissance métier en dehors de l’hexagone.
C’est le cas par exemple lorsqu’on fait des jointures dans une requête SQL. Une jointure utilise un lien entre 2 objets métiers. Ce lien est constitutif du domaine.
Supposons que l’on veuille éviter que les requêtes SQL aient la moindre connaissance du domaine. Cela nous obligerait à utiliser la couche applicative pour faire les jointures entre requêtes. Aïe… c’est du vécu (comme quoi, une bonne question peut mener à de mauvaises réponses).
Quelles sont les alternatives ?
À ce moment-là, il faut se demander quelles étaient les alternatives. 3 solutions s’offraient à nous :
-
Solution 1 : domaine et couche applicative parfaitement contenus dans le cœur de l’hexagone, mais en contrepartie un domaine qui connaît ses dépendances ;
-
Solution 2 (architecture hexagonale) : un domaine et une couche applicative qui ne sont pas pollués par leurs dépendances, mais en contrepartie une petite fuite de domaine à l’extérieur de l’hexagone ;
-
Solution 3 : un domaine et une couche applicative qui ne sont pas pollués par leurs dépendances et des dépendances qui ne connaissent rien du domaine. C’est très beau, mais ça n’existe pas.
C’est la même chose que les protocoles de tests médicaux. Un test de grossesse par exemple :
-
Si vous ne voulez aucun faux-positif, il faut accepter les faux-négatifs. La bonne option si vous espérez un enfant 🐣
-
Si vous ne voulez aucun faux-négatif, il faut accepter les faux-positifs. La bonne option si vous ne souhaitez pas d’enfant 🚫
Dans notre cas, la solution 3 n’en est pas une, donc il faut choisir entre les solutions 1 et 2.
L’architecture hexagonale fait le choix résolu de préserver le domaine du monde extérieur, car cela facilite le changement et le test.