Architecture hexagonale : de deux maux il faut choisir le moindre

Sur le papier, l'architecture hexagonale est le paradis du développeur.

À raison, car elle permet d'écrire le code du domaine en faisant abstraction des contingences matérielles du monde extérieur (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 bootstrap de l'application ;

• Une ACL (Anti-Corruption Layer), qui adapte la dépendance réelle à l'interface du domaine. Une façade et un adaptateur.

Pour nous, développeurs, c'est le paradis 🌞🏝️🌈. Chacun sa version du paradis, je vous l'accorde.

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 ACL 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 le domaine, et donc la couche applicative, pour faire les jointures entre requêtes. Totalement sub-optimal.

Et à ce moment-là, il faut se demander quelles étaient les alternatives. 3 solutions s'offraient à nous :

• Solution 1 : un domaine parfaitement contenu dans le cœur de l'hexagone, mais en contrepartie un domaine qui connaît ses dépendances.

• Solution 2 (architecture hexagonale) : un domaine qui n'est pas pollué par ses dépendances, mais en contrepartie une petite fuite de domaine à l'extérieur de l'hexagone.

• Solution 3 : un domaine qui n'est pas pollué par ses 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.

À la semaine prochaine 👋 !