Architecture hexagonale : reprenez le contrôle du code métier

Table des matières

Architecture hexagonale : reprenez le contrôle du code métier

Qu’est-ce qui rend particulière une application ?

Vous pouvez prendre 2 applications développées sur les mêmes technos, les mêmes frameworks ou ayant une structure applicative similaire : elles seront pourtant toutes les 2 bien différentes et grâce au code métier.

Le code métier, c’est le code que vous produisez pour un client pour répondre à ses besoins et ses exigences. C’est lui qui est d’ailleurs le plus de plus-value pour votre client, mais pour vous aussi.

Un client qui n’est pas un néophyte en matière de code s’en fiche complétèrent du framework ou des technos que l’on utilise.

Ce qui leur parle c’est le métier et si tu décris ton code comme leur métier le veut alors ça les intéresse.

C’est justement ce qui est mis à l’honneur dans l’architecture hexagonale : le code métier.

Un problème récurrent chez les développeurs

Comment est-ce que vous gérez le code métier de votre application ?

Moi de manière générale, je me cantonne à la structure proposée et prônée par mon framework et si je n’ai pas de framework, je me mets en place une structure applicative de type MVC par exemple.

Même si mon code est structuré, lisible et assez qualitatif, il y a tout de même un constat à faire : le code métier est éparpillé dans l’application.

Il est noyé dans un autre code : celui de l’application et de l’infrastructure.

L’architecture hexagonale va résoudre ce problème en isolant chaque partie de votre application.

Je ne l’ai pas encore précisé jusque là, mais cette architecture est à utiliser si vous construisez vos applications en POO.

L’architecture hexagonale dans le détail

L’architecture hexagonale a été inventée par un certain Alistair Cockburn qui l’a publiée en 2005.

Autant vous dire que c’est donc une architecture très récente dans le domaine du développement informatique.

Elle repose sur 3 couches différentes :

• le Domain
• l’Application
• l’Insfrastructure

Le Domain

C’est le coeur de votre application et de l’architecture. Le Domain va contenir tout le code métier de votre application.

Vous devez donc vous concentrer uniquement sur ce qu’il est censé faire sans prendre en compte la façon dont vous exposerez les données ainsi que leur stockage.

On va donc créer un ou plusieurs modèles sous forme de classe et vous allez y décrire vos propriétés, les méthodes qui manipulent votre objet, les contraintes et vérifications, etc.

Mais ce n’est pas tout. Vous allez également créer une ou plusieurs interfaces pour décrire ce qu’il sera possible de faire avec vos modèles.

Ce n’est pas le plus difficile à faire. Le plus difficile est de partir du principe que votre domaine ne doit dépendre de rien.

Donc pas de dépendance à l’Application, ni même à l’Infrastructure !

Bien entendu dans votre Domain vous allez très certainement devoir utiliser des packages externes et/ou librairies pour certains de vos besoins.

Mais, il faut garder à l’esprit que vous devez utiliser au maximum des librairies assez basiques comme des packages pour générer des identifiants uniques (uuid) ou une librairie de cryptage comme crypto.

Pour être sûr que votre Domain ne dépend pas de votre Application et de votre Infrastructure, je vous conseille de le développer de manière indépendante de votre projet et de l’intégrer au dernier au moment.

L’Application

C’est la partie de l’architecture qui va entre autres permettre de faire communiquer votre Domain avec l’Infrastructure.

L’Application connaît donc le Domain, mais elle ignore que la partie Infrastructure existe. En fait, elle n’a pas besoin de le savoir.

En général, l’Application est représentée sous forme de services. Vous allez y décrire concrètement le comportement de votre Domain en utilisant les interfaces précédemment décrites.

Quel est le bénéfice de faire cela ?

Vous allez pouvoir implémenter un peu de logique de manière indépendante du Domain.

Vous allez pouvoir par exemple filtrer, comparer ou tout simplement contrôler vos éléments renvoyés par les interfaces de votre Domain sans vous soucier de l’implémentation côté Infrastructure.

Un autre avantage et non des moindres c’est que vous pouvez faire évoluer la logique métier de votre Domain de manière indépendante de l’Application.

L’Infrastructure

On arrive à la finalité de l’architecture hexagonale.

Vous avez compris ! Le Domain ne dépend de rien, que l’Application connaît le Domain, mais pas l’Infrastructure.

La logique voudrait que l’Infrastructure connaisse l’application et uniquement cela.

Ce n’est pas tout à fait cela.

Votre Infrastructure va communiquer et utiliser les objets du Domain par le biais du service défini dans l’Application tout en implémentant les interfaces du Domain.

Rappelez-vous votre Infrastructure c’est votre API, votre base de données. Bref, c’est votre stack technique et il est temps de la faire entrer en jeu.

Et pour le faire, vous devez implémenter l’interface du Domain pour respecter l’implémentation du service de votre Application.

Donc à quoi va ressembler votre infrastructure ?

Supposons que vous souhaitez réaliser une API avec le framework NestJS et que vous avez choisi comme base de données pour le stockage MongoDB.

Votre infrastructure va contenir toute la magie de NestJS qui permet son bon fonctionnement. Vous allez y définir des contrôleurs qui appelleront vos services (donc votre Application).

Vous allez y définir votre connexion à votre base de données qui sera utilisée dans ce qu’on appelle un Repository.

Le Repository va implémenter l’interface du Domain. Et c’est là que vous allez écrire le code permettant de stocker vos données en base de données.

Il vous suffira ensuite dans votre infrastructure de faire en sorte que votre service (l’Application) utilise votre Repository par le biais l’interface de votre Domain.

Quel est le bénéfice de faire cela ?

Supposons que demain vous souhaitez changer de framework, vous devrez juste recoder la partie infrastructure en intégrant votre nouveau framework. Pas besoin de recoder le Repository.

De même, vous souhaitez changer de moteur de base de données, il vous suffira de coder un nouveau Repository qui remplacera celui de MongoDB. Pas besoin de retoucher autre chose à côté de cela.

Les avantages de l’architecture hexagonale

Comme je l’ai dit en introduction, le bénéfice majeur est de rendre indépendant le code métier du reste de l’application.

Vous pouvez faire évoluer votre Domain simplement sans risquer de tout casser derrière. Et il en va de même pour les autres parties.

Un autre avantage et pas des moindres ce sont les tests. La réalisation des tests unitaires est beaucoup plus accessible et simple comme les dépendances de chaque partie ne vont que dans un sens.

Il est donc tout à fait possible de créer des Repository pour vos tests unitaires afin de stocker les données en mémoire par exemple.

Enfin avec cette architecture, vous avez la garantie que votre code métier sera pérennisé, car il peut être extrait facilement pour travailler dans une autre infrastructure différente.

La seule et unique contrainte que vous aurez selon moi c’est votre langage de programmation.

Car, si vous souhaitez basculer votre code métier dans un autre langage de programmation, vous devrez la recoder, mais ce sera plus simple et plus rapide.

Les inconvénients de l’architecture hexagonale

Il faut quand même reconnaître que ce genre d’architecture est assez complexe à comprendre et à mettre en place.

Il n’est pas recommandé aux programmeurs débutants de s’y attaquer s’il n’a pas déjà une expérience solide d’autres architectures.

Même moi, avec mon expérience, j’ai bien galéré à comprendre et à mettre en application l’architecture.

Car avec cet article, je vous ai simplifié son concept et les explications pour que ce ne soit pas trop lourd à comprendre et à lire.

Un autre inconvénient c’est que l’architecture hexagonale s’adresse au projet que vous comptez réaliser en POO.

Enfin dernier inconvénient, il est difficile de mettre en place une architecture hexagonale dans une architecture existante.

Je suis en train de l’apprendre à mes dépens, car je suis obligé de créer du code supplémentaire en mode hybride pour faire fonctionner le tout.

Alors même si cela marche, il faut reconnaître que cela peut complexifier certaines parties de code.

A faire uniquement si vous êtes sûr que vous aurez la possibilité de repasser sur l’ensemble de votre application pour la basculer complément en architecture hexagonale.

Epilogue

Je vous avoue que j’ai été complètement conquis par cette architecture hexagonale. Je trouve qu’à l’heure d’aujourd’hui c’est pour moi le saint Graal en termes d’architecture d’application BackEnd.

Et je ne peux que vous conseiller de l’utiliser dans vos projets si vous avez les connaissances et le niveau requis pour l’utiliser.

Je vous donne un lien d’un repository Github dont je me suis inspiré pour réaliser mon architecture hexagonale sur NestJS : https://github.com/ogranada/nestjs-hex 🔗.

Je vous partage une série de vidéos où j’implémente l’architecture hexagonale en Typescript :