C’est à Alistair Cockburn qu’on doit le concept d’architecture hexagonale, développée sur son blog en 2005. Depuis le milieu des années 2010, on constate qu’il rencontre un franc succès auprès de celles et ceux qui souhaitent développer une application mobile ou web.
Qu’est-ce que l’architecture hexagonale ?
Comment la mettre en place dans le cadre d’un projet ?
Focus sur cette notion qui place le métier au cœur de sa logique.
D’où vient l’Architecture Hexagonale ? 🤔
Introduit par Alistair Cockburn, l’Architecture hexagonale est également connue sous le nom de “Port & Adapters Architecture”. De ce principe ont ensuite émergé des patterns d’architecture logiciel assez proches, comme la Clean Architecture.
L’avis de l’expert theTribe
“Les problématiques d’architecture se sont posées à partir du moment où on a commencé à écrire du code, à savoir dans les années 60. Le modèle MVC a émergé à la fin des années 70 et s’est imposé comme l’une des architectures les plus populaires. C’est un patron qui a beaucoup évolué avec le temps, mais qu’on utilise toujours aujourd’hui.
À partir des années 2000, pourtant, le modèle MVC s’est confronté à un problème : on a commencé à développer des logiciels de plus en plus complexes, des projets plus gros, qui utilisent plus de volume… En conséquence, des cas métiers qui, de base, étaient d’une simplicité déconcertante, se sont retrouvés avec un code qui partait dans tous les sens et qui nécessitaient un tas de dépendances pour fonctionner.
De là est née la nécessité de proposer un nouveau type d’architecture, telle que l’architecture hexagonale.”
Pierre-Louis Legrand, Back End Developer
Définition de l’Architecture Hexagonale 📝
👉 Le métier au centre de l’architecture
La logique de ce pattern d’architecture repose sur une idée assez simple : il faut isoler la logique métier des services techniques d’une application. Ce principe peut être mis en relation avec le Domain-Driven Design (DDD), et ces deux concepts peuvent être complémentaires.
Concrètement, il existe un dedans, qu’on appelle métier ou business, et un dehors, qui désigne les détails techniques et infrastructures. La règle d’or étant que le métier doit être totalement indépendant, c’est-à-dire que c’est l’infrastructure qui dépend du domaine. En d’autres termes, toutes les dépendances vont de l’extérieur vers l’intérieur.
L’avis de l’expert theTribe
“Beaucoup de gens ont des a priori sur l’architecture hexagonale parce qu’ils pensent qu’elle ne sert qu’à faire plaisir aux développeurs et qu’elle pénalise le produit. C’est en fait l’inverse, puisqu’elle a émergé pour servir le produit et le replacer au cœur du développement.
Ce nouveau paradigme est né d’un constat : que l’on faisait de la tech qui ne rendait plus du tout service au produit. Avec l’architecture hexagonale, on décide justement de remettre le produit au cœur de la technique, et la technique au service du produit.”
Pierre-Louis Legrand, Back End Developer
👉 La métaphore des Ports et Adapteurs
Pour mieux comprendre le principe de l’architecture hexagonale, et la logique de l’intérieur et de l’extérieur, on peut prendre la métaphore des ports et des adapters. Le métier définit des ports, sur lesquels il est possible de brancher des adapters, qui se trouvent à l’extérieur.
Ils sont absolument essentiels car ils font en quelque sorte office de traducteurs entre le monde extérieur et l’hexagone, c’est-à-dire entre le code métier et la couche Infrastructure. Les ports sont définis par l’hexagone et servent d’interface avec le monde extérieur.
Les grands principes de l’Architecture Hexagonale ⚙️
Rentrons davantage dans les détails de l’Architecture Hexagonale, en s’intéressant de plus près à ses principes fondateurs. Elle repose en effet sur quelques piliers essentiels.
👉 Préserver le métier
La logique métier constitue la plus grande valeur ajoutée d’un logiciel. C’est pourquoi il est absolument essentiel de préserver le métier en le distinguant des processus techniques. Pour cela, il faudra donc commencer par isoler les deux en tentant de comprendre avec précision ce qui constitue la logique métier.
C’est le principe même de l’architecture en couches, dans lequel le domaine doit se trouver à l’intérieur de l’hexagone, sans faire appel à aucun élément extérieur. L’hexagone représente ainsi la séparation nette entre le code métier et le code technique, auquel on se réfère également en tant que “couche Infrastructure”. Ainsi, l’objectif est de limiter l’impact des changements techniques sur la logique métier de l’hexagone.
L’avis de l’expert theTribe
“On fait ce découpage car le but qu’on cherche à remplir, c’est d’isoler la partie domaine et application, c’est-à-dire la partie métier. On veut la protéger le plus possible, afin qu’elle ne dépende de rien du tout. Ainsi, c’est tout l’extérieur qui dépend des règles métier.”
Pierre-Louis Legrand, Back End Developer
👉 Architecture en couches
Pour illustrer au mieux le concept de l’architecture hexagonale, il faut le concevoir comme un système basé sur des couches. Au centre : la logique métier, qui est entourée de plusieurs autres couches correspondant à la partie technique.
👉 Le Business
Il correspond à la logique métier dont nous avons tant parlé auparavant. C’est le centre de l’hexagone et l’élément qui doit ne dépendre d’aucun autre.
L’avis de l’expert theTribe
“ Au centre de l’hexagone, on retrouve les règles business, qui sont des règles propres au métier de l’application. On peut les séparer en deux catégories distinctes : une propre aux entités, c’est-à-dire aux objectifs physiques eux-mêmes, et une propre à l’application même.”
Pierre-Louis Legrand, Back End Developer
👉 La couche Application
C’est la couche qui sépare le monde extérieur de l’hexagone. L’application correspond aux cas d’usages métiers du produit, autrement dit, les différentes actions qu’on peut faire avec.
👉 La couche Infrastructure
Cette couche permet de traiter les communications qui viennent de l’extérieur et de les adresser aux adaptateurs. Les adaptateurs de l’infrastructure se branchent ainsi sur les ports de l’application pour l’exploiter et faire le pont entre celle-ci et le monde extérieur (les utilisateurs, et les services tiers).
Les avantages à mettre en place l’Architecture Hexagonale 🎯
L’avis de l’expert theTribe
“Il y a plusieurs intérêts majeurs à mettre en place une architecture hexagonale :
1 – D’une part, on peut commencer à travailler sur la partie métier en premier, étant donné qu’on ne dépend de rien. On peut le faire sans savoir ce qu’on va employer comme solution technique. C’est donc un réel gain de temps.2 – On est certain de faire une partie métier isolée du reste, sans dépendance, ce qui permet de la protéger face aux changements qui viennent de l’extérieur. Cela garantit une stabilité “optimale” et une durabilité à long terme de la base du code, afin de garder une maîtrise complète sur le métier.
3 – On peut tester automatiquement de manière plus simple, parce que le métier n’a pas de dépendance donc son exécution est simple et rapide, mais aussi parce que pouvoir brancher les adaptateurs de nos choix sur les ports permet plus facilement d’optimiser l’environnement de test du produit. Cela encourage des méthodes de travail comme le TDD, qui consiste à écrire les tests avant d’écrire le code. Ainsi, on garantit que le code métier est recouvert d’une couverture de test plus complète.
4 – S’imposer des paradigmes (normes/conventions) permet d’automatiser le process de développement (gain d’efficacité) et de faciliter l’arrivée d’un développeur sur un projet sans être perdu dans son architecture.
5 – Enfin, on rend le code et son organisation bien plus explicites à la lecture, ce qui fait que tous les projets répondent aux mêmes normes et aux mêmes conventions.”
Pierre-Louis Legrand, Back End Developer
Pour aller plus loin sur l’architecture hexagonale… 🚀
- Un article d’Alistair Cockburn, l’un des théoriciens majeurs de l’architecture hexagonale.
- Plusieurs articles de Matthias Noback :
- Le blog de Uncle Bob, The Clean Code Blog
