L'architecture Hexagonale

Dans cet article, nous allons présenter l’architecture hexagonale, qui répond à de nombreux besoins.

Dans le monde de l’IT on cherche toujours à mettre en place des solutions évolutives, faciles à maintenir, et surtout des applications bien organisées. Nous avons toujours des défis de migrations, que ce soit des technologies, leurs versions, ou même le découpage des applications pour casser l’ancienne approche monolithique.

Une autre chose à souligner, lorsque dans la plupart des applications le choix technique est fait, il est difficile de changer après un bon avancement, car on sera exposé à des régressions, et tout en avançant on se rapproche du point de non-retour.

Et même si l’application peut rester stable, on aura besoin parfois de changer les sources des données.

I. Définition et historiques de l’architecture hexagonale :

L’architecture Hexagonale s’appelle aussi architecture à base de ports et d’adaptateurs, inventée par Alistair Cockburn en 2005.

C’est une architecture logicielle, comme expliqué dans l’article d’Alistair, où il dit que l’architecture hexagonale permet le pilotage de l’application aussi bien par des utilisateurs que par des programmes, des scripts batchs ou des tests automatisés, et que cette application soit aussi développée et testée en isolation des bases de données et des systèmes d’exécution.

Le principe de base de l’architecture hexagonale est l’isolation de la partie métier de l’application, cela nous fait penser au DDD (Domain Driven Design) qui donne au domaine métier plus d’importance que la technologie.

NB : L’architecture hexagonale et le DDD peuvent se renforcer, mais ils sont bien distincts.

II. Principe de l’Architecture Hexagonale :

L’architecture Hexagonale se base sur des principes simples (3 principes) :

L’isolation de la logique métier de son implémentation en termes de détails techniques :

Là on parle de la séparation de trois parties de l’application : Métier (Business Logic), Présentation (User-Side) et Persistance (Server-Side).

Mais comme son nom l’indique, la partie Métier sera isolée dans un Hexagone (facile à dessiner).

La partie Métier ne dépend de rien, c’est plutôt l’infrastructure qui dépend du métier.

C’est le 2^ème principe : Les dépendances vont de l’extérieur vers l’Hexagone
Les Parties Persistance et Présentation dépendent du métier.

Isolations par des Ports et Adaptateurs.

Ce principe est décrit par le fait que dans le contexte de l’architecture hexagonale, c’est l’infrastructure qui s’adapte, puisque le métier ne dépend jamais de l’infrastructure, mais l’inverse. Et pareil pour la partie présentation.

Autrement dit, tout changement de type de base de données n’impacte pas la partie métier, mais plutôt les adaptateurs.

Mais deux questions qui se posent, comment notre partie métier va savoir quel fournisseur de données va la contacter ? Et comment rendre le modèle iso-fournisseur ?

De l’autre coté (coté Présentation) comment cacher notre cœur métier ?

Là on va se servir de principe SOLID, sur la partie Inversion de dépendance.

Utilisation des interfaces avec un sens purement métier connu par notre modèle.
Grace à l’Adaptateur, l’implémentation sera fournie, mais ne sera résolue qu’à l’exécution.
Donc tout changement affectera juste l’implémentation des interfaces mais pas le modèle : le changement est transparent. On parle d’un couplage Faible.

Et pour aller plus loin dans l’organisation de code, on peut regrouper les interfaces dans deux sous-parties (packages) :

API (Application Provider Interface) : les interfaces qui seront exposées pour les composants ayant besoin d’appeler le modèle.
SPI (Service Provider Interface) : les interfaces qui seront implémentées pour récupérer les données de l’infrastructure.

NB : Elles (API et SPI) doivent avoir un sens métier.

Pour conclure sur cette partie, ci-dessous un schéma illustrant l’architecture hexagonale :

III. Bonne utilisation de l’architecture hexagonale :

L’architecture hexagonale n’est pas une solution magique :

Avant d’implémenter l’architecture hexagonale, il faut se poser les deux questions suivantes « Est-ce que mon application peut exister si je change les technologies ? Est-il possible d’extraire une partie métier ? » si c’est oui comme réponse pour les deux : L’architecture hexagonale est un bon candidat.

Tout simplement, l’architecture hexagonale est efficace dans un contexte où le métier est important et/ou complexe avec une stabilité si les technologies changent.

Commencez par l’hexagone :

Vous pouvez mettre en place votre métier, au début, et pour s’assurer que votre implémentation est bien faite, vous pouvez vous servir des mocks par exemple.

Faites vivre votre hexagone :

La connaissance change au fils de temps, donc il faut savoir que votre modèle métier n’est pas stable que ce soit pour un changement ou une évolution.

Prenez soins des interfaces :

Les interfaces font partie de l’hexagone et donc du modèle métier. En conséquence, il faut faire attention à ce qu’elles gardent un sens purement métier.

IV. Avantages et Inconvénients :

1.1. Avantages :

Moins de risques de régressions fonctionnelles, en cas de changement technique :

Comme c’est mentionné dans cet article, le métier (Hexagone) est séparé de l’infrastructure et de ses détails è donc un changement au niveau de l’infrastructure par exemple n’engendre pas une régression sur le métier de l’application.

Application plus évolutive :

Il est plus simple d’ajouter des nouvelles fonctionnalités et d’en changer certaines existantes, puisque les connaissances métiers ne seront pas perdues.

Simplicité de test de la partie métier :

Vu que la partie métier est bien isolée dans l’hexagone de la partie infrastructure, si on veut tester la partie métier, on ne va s’occuper que de la couche modèle indépendamment de la source des données (Base de données, Fichiers, des applications, etc).

Livrables préparés rapidement :

Vu que le métier ne dépend pas de l’infrastructure et la partie présentation, on peut préparer des livrables rapidement, testés via des mocks.

Elle favorise les approches BDD et DDD.

1.2. Inconvénients :

Augmentation du nombre de packages :

A cause de l’organisation des fichiers, on aura besoin de créer beaucoup plus de packages qu’une architecture tierce par exemple.

Inefficacité dans certains cas :

L’utilisation de l’architecture Hexagonale dans un mauvais contexte peut complexifier le code.

V. Implémentation de l’architecture Hexagonale :

1.1. Contexte :

Il s’agit d’une application web qui permet de gérer les actions bancaires (Déposer, Retirer).

1.2. Implémentation :

On commence par le modèle métier :
- Il faut faire gaffe pour créer un modèle indépendant des technologies :

Passons ensuite aux Ports :

Notre hexagone va devoir communiquer avec l’extérieur (Présentation et Persistance), pour cela on aura une interface par contrat d’API pour chaque action.

Commençons par la Partie API, on a deux actions à gérer :