Pérennisez votre métier avec l’architecture hexagonale !

Dans la majorité des DSI où nous intervenons, nous faisons souvent le même constat depuis plusieurs années ; il reste difficile de produire des applications évolutives et pérennes. C’est d’autant plus vrai aujourd’hui alors que la révolution numérique (ne dites surtout pas digitale) bat son plein, entrainant des nouveautés incessantes en termes de technologies, d’outillage, etc. Ainsi, il est assez courant d’entendre que la durée de vie d’une application ne dépasse pas 4-5 ans et toute ou partie de la connaissance métier se perd après chaque redémarrage à zéro, malgré toute la bonne volonté du monde.

Plus précisément, nous observons chez nos clients :

• Des choix techniques précipités. Ces derniers sont la majorité du temps faits au début du projet, alors que la connaissance est à son niveau le plus faible (volume d’utilisateurs, pics de charge, adéquation aux contraintes métier). C’est un pari sur le futur qui s’avère souvent désastreux et se fait au détriment de la connaissance métier, qui elle aussi est à son niveau le plus bas.

• Un immobilisme technique. Une fois ces choix techniques faits, il est souvent difficile voire impossible de s’en défaire. Cela nécessite la plupart du temps de re-tester le périmètre complet de l’application et induit un très fort risque de régressions. Plus le temps passe, plus l’application grossit et plus l’immobilisme grandit jusqu’à atteindre un point de non-retour. Ce problème trouve son origine dans l’incapacité des équipes à séparer la logique métier des technologies, frameworks et outils utilisés.

• Une faible testabilité de la logique métier. Ne pas séparer la logique métier de l’infrastructure n’a pas que des impacts techniques. Dans bien des équipes, les tests fonctionnels font intervenir un grand nombre de couches techniques (bases de données, middlewares). De ce fait, ils sont souvent longs à s’exécuter, le sont rarement (au mieux une fois par jour) et sont friables. Au final, ils sont souvent rares voire même abandonnés car la boucle de feedback est trop longue et trop difficile à mettre en place. En conséquence, les testeurs (ou QA) perdent la majorité de leur temps à répéter manuellement des tests qui pourraient être automatisés, réduisant ainsi la part exploratoire de leur travail. Ceci n’est évidemment pas sans conséquence sur la qualité finale de l’application.

Pour faire face à ces problèmes, il convient de faire usage d’une approche isolant logique métier et couches techniques.
Chez Xebia, nous pensons que c’est essentiel afin :

• d’assurer la pérennité du métier de son application (les technologies doivent pouvoir changer sans risque de régression) ;
• de renforcer l’appétence des équipes au métier, voie royale vers une plus grande qualité et une plus grande adéquation des livrables aux besoins clients.

Dans cet article, nous vous proposons de découvrir l’une de ces approches : l’architecture hexagonale.

Complément d’information

Il nous parait important de mentionner que cet article trouve son inspiration dans de multiples sources comme cette excellente présentation faite à Devoxx’ 15 par Cyrille Martraire et Thomas Pierrain. Il ne se veut en aucun cas une retranscription de cette dernière mais un partage de connaissance quant à son usage intensif depuis 2 ans sur l’un des projets où nous intervenons.

Origines

L’architecture hexagonale est ce que l’on pourrait appeler un pattern d’architecture. Il a été introduit sous ce terme par Alistair Cockburn au milieu des années 2000 et a été ensuite renommé en « Ports & Adapters ». Depuis, bon nombre d’auteurs ont publié des patterns semblables dont Uncle Bob (Clean Architecture) et Jeffrey Palermo (Onion Architecture).  Les concepts que nous allons détailler dans cet article s’appliquent bien souvent à l’ensemble de ces variantes.

Concepts

L’architecture hexagonale repose sur une idée très simple : isoler la logique métier des détails techniques de son implémentation.
Il existe un dedans (le métier ou modèle) et un dehors (les détails techniques ou infrastructure).

Le principe fondateur de ce pattern est que le métier ne dépend de rien. C’est donc l’infrastructure qui dépend du métier.
Autrement dit, toutes les dépendances vont de l’extérieur vers l’intérieur, sans exception.
Une fine couche d’adaptation, contenue dans l’infrastructure, se charge de faire le lien entre les deux mondes.

 

Un modèle agnostique de l’infrastructure

Le modèle ne contient aucune référence technique. Vraiment aucune. En d’autres termes, il ne contient pas de framework, pas de base de données, pas de middleware, pas d’accès réseaux, pas d’écriture/lecture sur disque, pas d’annotations liées à un ORM, etc. Le modèle, c’est un langage nu et c’est tout ! Il ne doit jamais y avoir une dépendance du modèle vers l’infrastructure.

Le modèle expose des interfaces qui ont un sens métier.
On trouve d’une part des interfaces exposées pour les composants ayant besoin d’invoquer le modèle. On parle d’API (Application Provider Interfaces).

Et d’autre part, des interfaces exposées pour les composants que le modèle a besoin d’invoquer. On parle de SPI (Service Provider Interfaces).

Comme ces interfaces font partie du modèle, elles ne doivent contenir aucune sémantique liée à l’infrastructure.
Elles doivent absolument avoir un sens métier.

Une infrastructure qui s’adapte

Nous l’avons vu précédemment, le métier ne dépend jamais de l’infrastructure. C’est cette dernière qui dépend du métier et se doit de s’adapter.
Autrement dit, si nous changeons de type de base de données, nous n’aurons qu’à changer un adaptateur et nous n’aurons pas à toucher notre couche métier.

Toutes les dépendances vont donc de l’extérieur vers l’intérieur. Pour les composants qui appellent notre métier, c’est facile. Ils n’ont qu’à contacter nos API.
Mais quid des fournisseurs que notre métier va avoir besoin de contacter ? Comment faire en sorte que notre modèle n’en ait pas connaissance ?

La réponse est relativement simple. Nous allons faire usage d’un principe SOLID, le « Dependency Inversion Principle » (DIP).

L’idée est que notre modèle ne connaisse qu’une interface ayant un sens purement métier. L’implémentation ne sera résolue qu’à l’exécution et c’est le rôle de l’adaptateur que de la fournir. Si notre technologie sous-jacente change, l’implémentation de l’interface changera également mais ce sera transparent pour notre modèle. On obtient ainsi une forte cohésion de notre métier et un faible couplage entre les deux couches (« Low coupling, high cohesion »).

Au final, l’architecture de notre application aura la forme suivante :

Les composants souhaitant communiquer avec notre métier le feront au travers d’adaptateurs qui contacteront nos API. Leurs implémentations font partie de notre modèle et ne sont pas visibles à l’extérieur de l’hexagone.
À l’inverse, les composants avec lesquels notre métier souhaite communiquer seront contactés au travers des SPI dont les implémentations seront résolues à l’exécution et fournies par des adaptateurs.

Gains

Une testabilité du métier accrue

Les concepts que nous venons de voir permettent de séparer le métier de l’infrastructure.  Ainsi, si nous souhaitons tester notre métier, nous n’avons qu’à nous occuper de la couche du modèle. Et c’est un gain considérable ! Nos tests ne dépendent plus d’une base de données, d’un middleware ou de lectures/écritures sur disque ; ils se trouvent donc sensiblement accélérés ! Il suffit d’envoyer un message sur une API et de brancher une implémentation de test (fake, stub, mock) sur l’une des SPI. Et le tour est joué !

En conséquence, la boucle de feedback est extrêmement rapide ; la non-régression est assurée quasi-instantanément. De ce fait, la couverture métier est plus aisée et devient généralement plus large. En résulte une facilité à tester qui permet de délester les testeurs de leurs tâches répétitives pour les laisser se concentrer sur les tests exploratoires. C’est un cercle vertueux qui aboutit généralement à une qualité accrue des livrables.

Une pérennisation du métier face aux changements techniques

Puisque le métier est séparé des détails d’infrastructure, un changement technique n’a plus aucun risque d’introduire une régression fonctionnelle.
Ainsi, il devient aisé :

• de changer de solution technique lorsque celle-ci n’est plus adaptée (augmentation du nombre d’utilisateurs par exemple) ;
• de tester une nouvelle solution qui parait prometteuse (et ce, en parallèle de l’existante).

Le changement n’est plus source de peur et l’application n’est plus figée dans ses choix techniques initiaux. D’autre part, le métier de l’application est pérennisé. Cela ne veut pas dire qu’il n’évolue pas mais il ne subit plus la loi des changements techniques. Ainsi, la durée de vie des applications s’allonge et les connaissances métiers acquises sont capitalisées.

Une capacité à livrer de la valeur rapidement

Au démarrage d’une application, l’usage de l’architecture hexagonale permet de démontrer rapidement puisque l’on ne dépend plus de contraintes extérieures comme l’infrastructure.
On peut aisément remplacer une base de données par un fichier plat ou une application web par une ligne de commande et cela suffit amplement à proposer un MVP au bout du premier sprint. On repousse ainsi les choix techniques à plus tard, au moment où notre connaissance sera plus à même de faire un choix éclairé. Mieux, on se concentre sur le besoin client (le métier) et l’on accélère la boucle de feedback pour s’assurer que l’on se trouve sur la bonne voie.

Et mon modèle en couches alors ?!

L’une des questions les plus fréquemment posées à propos de l’architecture hexagonale est : « quelle est la différence avec un bon vieux modèle en couches ? »
Arrêtons-nous quelques instants pour tenter d’y répondre. Traditionnellement, beaucoup d’applications sont architecturées selon trois couches :

_{(Credits schéma - http://matteo.vaccari.name/blog/archives/154)}

Généralement, la couche présentation ne connait que la couche métier qui elle même ne connait que la couche de persistance. Si les choses ont été bien faites, une couche ne connait pas l’implémentation de la couche dont elle dépend via l’usage du « Dependency Inversion Principle » (DIP). C’est l’usage de ce principe qui laisse à penser qu’il existe une équivalence entre les deux architectures alors que la différence est bien marquée.

Posons-nous la question suivante : « où se situe notre logique métier dans cette architecture traditionnelle en couches » ? Intuitivement, on pourrait penser qu’elle se trouve dans la couche du même nom.
Or, cette dernière contient la plupart du temps des services sans état qui travaillent sur les entités venant… de la couche de persistance ! Du coup, notre métier est partagé entre la couche métier et la couche de persistance.

Pire, les entités de cette dernière sont souvent complétées d’annotations liées à un ORM (ce qui représente un détail d’infrastructure) et sont anémiques, c’est à dire sans comportement. On pourrait être tenté de regrouper ces deux couches mais on se retrouve alors à mélanger logique métier et détails d’implémentation et l’on en revient aux problématiques énoncées au début de cet article.

À l’inverse, si l’on regarde l’architecture hexagonale sous une vue « en couches », voici ce que l’on obtient :

_{(Credits schéma - http://matteo.vaccari.name/blog/archives/154)}

Le métier ne dépend de rien et les autres couches dépendent du métier. Contrairement à une architecture en couches traditionnelle, état et comportement sont co-localisés bien à l’abri des détails techniques de l’infrastructure.

Nos conseils pour faire un usage pragmatique de l’architecture hexagonale

Faites vivre votre modèle métier

Pérenniser votre métier ne signifie pas le figer dans le marbre. N’oubliez jamais que votre modèle représente votre connaissance à un instant T.
Il convient donc de l’enrichir, de le faire évoluer dans le temps et de montrer une réelle appétence pour le métier que vous supportez au travers d’une communication riche et d’un langage partagé avec les experts. Des pratiques comme le « Behavior Driven Development » (BDD) et le « Domain Driven Design » (DDD) vous y aideront. Notez que l’utilisation de l’architecture hexagonale facilite grandement leur mise en place même si elle n’est pas systématique.

Prenez soin de vos interfaces

Les objets contenus dans vos interfaces font partie intégrante de votre modèle et il convient d’y porter une grande attention. Prenez garde à ce que les interfaces et leurs objets gardent un sens purement métier. Veillez à ne pas ajouter de complexité accidentelle dans votre hexagone ; fuyez les chaines de caractères, favorisez les types forts et les énumérations. 

Ne tentez pas d’absorber toute la variété métier disponible à l’extérieur de l’hexagone mais construisez un modèle cohérent.
Gardez en tête que ces interfaces et objets vont évoluer au cours du temps pour permettre la mise en œuvre de nouvelles fonctionnalités.

Commencez toujours par le cœur de votre hexagone

Un exercice intéressant consiste à développer l’ensemble de votre hexagone avant de vous attaquer aux détails techniques.
Pour ce faire, laissez-vous guider par les tests (BDD) et remplacez temporairement l’infrastructure par des mocks, stubs ou fakes.

À l’arrivée, vous obtiendrez un modèle bien plus cohérent, nettoyé de tout détail technique puisque ne communiquant que via ses API et SPI « métier ».
Ce dernier sera dans bien des cas suffisant pour démontrer à votre client et ainsi obtenir un premier feedback sur l’adéquation de votre travail.

Vous pourrez par la suite renforcer la séparation métier/infrastructure en créant par exemple des modules séparés.
C’est un excellent moyen pour éviter toute dépendance malencontreuse du métier vers les détails techniques.

N’utilisez pas l’architecture hexagonale à toutes les sauces

Comme tout pattern ou pratique, il convient de faire preuve de pragmatisme. L’architecture hexagonale n’est pas conseillée dans certains cas, notamment si votre application est un composant purement technique, dénué de toute logique métier. Pour le savoir, posez-vous la question suivante : « si telle ou telle technologie change, est-ce que mon composant continue d’exister » ? Si la réponse est non, ne vous embêtez pas à construire un hexagone. Dans le cas contraire, interrogez-vous ; votre application pourrait bien contenir un métier dont vous ignoriez l’existence…

Plus généralement, l’architecture hexagonale est conseillée si votre métier est riche et/ou complexe. Elle favorise les pratiques telles que le BDD, le DDD et l’appétence au fonctionnel en général.
Mieux, elle peut être répétée dans plusieurs composants communiquant les uns avec les autres (qui a dit bounded contexts ?!).

TL; DR

Dans cet article, nous avons présenté l’architecture hexagonale pour répondre à trois constats observés sur le terrain par nos consultants :

• des choix techniques précipités ;
• un immobilisme technique ;
• une faible testabilité de la logique métier.

Nous avons vu comment, en séparant métier et infrastructure, ce pattern offrait :

• une testabilité du métier accrue ;
• une pérenisation du métier face aux changements techniques ;
• une capacité à livrer de la valeur rapidement.

Enfin, nous vous avons donné quelques conseils pour une mise en œuvre pragmatique.
Dans un prochain article, nous vous proposerons des exemples d’implémentation pour concrétiser la partie théorique abordée dans celui-ci.