Architecture hexagonale
L'architecture hexagonale, ou architecture à base de ports et d'adaptateurs, est un patron d'architecture utilisé dans le domaine de la conception des logiciels. Elle vise à créer des systèmes à base de composants d'application qui sont faiblement couplés et qui peuvent être facilement connectés à leur environnement logiciel au moyen de ports et d'adaptateurs. Ces composants sont modulaires et interchangeables ce qui renforce la cohérence des traitements et facilite l'automatisation des tests[1].
Origine[modifier | modifier le code]
L’architecture hexagonale a été inventée par Alistair Cockburn dans le but d’éviter les pièges habituels de conception de logiciels orientés objet rencontrés dans les architectures en couches, comme par exemple les dépendances indésirables entre les couches et la contamination du code de l’interface utilisateur avec des logiques et des règles métier. Elle a été publiée en 2005[2].
Le terme « hexagonal » réfère aux conventions graphiques informelles, qui représentent les composants d'application sous forme de cellule hexagonale. Le but n'est pas de suggérer qu'il y aurait six frontières / ports, mais de laisser suffisamment de place pour représenter les différentes types d'interface nécessaires entre le composant et le monde extérieur[1].
Principes[modifier | modifier le code]
L'architecture hexagonale décompose un système en plusieurs composants interchangeables et faiblement couplés, tels le noyau de l'application, la base de données, l'interface utilisateur, les scripts de test ou encore les interfaces avec d'autres systèmes.
Chaque composant est connecté aux autres par l'intermédiaire de « ports » qui représentent un canal de communication. La communication via ces ports suit un protocole qui dépend de l'objectif de l'interaction. Les ports et les protocoles définissent une interface de programmation applicative (API) abstraite, qui peut être mise en œuvre par tout moyen technique approprié (par exemple : invocation de méthodes dans un langage orienté objet, appels de procédure distante ou encore services Web).
La granularité des ports et leur nombre n'est pas contraint :
- un seul port pourrait, dans certains cas, être suffisant (par exemple, dans le cas d'un simple consommateur de service);
- En général, il existe des ports pour les sources d'événements (interface utilisateur, alimentation automatique), les notifications (notifications sortantes), la base de données (afin d'interfacer le composant avec un SGBD approprié) et pour l'administration (pour contrôler le composant);
- dans un cas extrême, il pourrait y avoir un port différent pour chaque cas d'utilisation, si nécessaire.
Les adaptateurs forment le ciment entre les composants et avec le monde extérieur. Ils adaptent les échanges entre le monde extérieur et leur port, ce dernier traduisant des exigences internes au composant d’application. Il peut y avoir plusieurs adaptateurs pour un même port, par exemple lorsque les données peuvent être fournies par un utilisateur via une interface graphique ou une interface de ligne de commande, ou envoyées par une source de données automatisée ou des scripts de test.
Usage, critique et évolution[modifier | modifier le code]
Selon Martin Fowler, l'architecture hexagonale présente l'avantage d'utiliser des similitudes entre la couche de présentation et la couche de source de données pour créer des composants symétriques constitués d'un noyau entouré d'interfaces, mais avec l'inconvénient de masquer l'asymétrie inhérente entre un producteur de services et un consommateur de services[3].
Selon certains auteurs, l’architecture hexagonale serait à l’origine de l’architecture à base de microservice[4].
Variantes[modifier | modifier le code]
L’architecture en oignon, proposée par Jeffrey Palermo en 2008, est similaire à l’architecture hexagonale. En effet, elle externalise également l’infrastructure en utilisant des interfaces appropriées pour garantir l'absence de couplage entre l’application et la base de données[5]. Elle décompose toutefois le noyau d’application de façon plus précise, sous forme d'anneaux concentriques utilisant l’inversion de contrôle[6].
L’architecture « épurée » (« clean architecture » en anglais), proposée par Robert C. Martin en 2012, combine les principes de l’architecture hexagonale, l’architecture en oignon et plusieurs autres variantes architecturales. Il propose ainsi des niveaux de détail supplémentaires du composant, qui sont présentés sous forme d'anneaux concentriques. Cette architecture isole les adaptateurs et les interfaces (interface utilisateur, bases de données, systèmes externes, des appareils) dans les anneaux extérieurs de l'architecture et dédie les anneaux intérieurs pour les cas d'utilisation et les entités[7],[8]. L'architecture « épurée » utilise le principe d'inversion des dépendances avec la règle stricte selon laquelle les dépendances ne doivent exister qu'entre un anneau externe et un anneau plus interne et jamais le contraire.
Voir aussi[modifier | modifier le code]
- Patron d'architecture
- Architecture logicielle
- Diagramme de structure composite
- Analyse et conception orientée objet
- Architecture en couches
Références[modifier | modifier le code]
- (en) Alistair, « Hexagonal architecture » [archive du ], alistair.cockburn.us,
- (en) Jan Stenberg, « Exploring the Hexagonal Architecture », sur InfoQ.com, InfoQ, (consulté le )
- (en) Martin Fowler, Patterns of enterprise application architecture, Addison-Wesley, , 533 p. (ISBN 978-0-321-12742-6, OCLC 50292267, lire en ligne), p. 21
- (en) R V Rajesh, Spring 5.0 microservices : build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos, Packt Publishing, , 414 p. (ISBN 978-1-78712-051-8, OCLC 999610958, lire en ligne), p. 13-14
- (en) Jeffrey Palermo, « The Onion Architecture : part 1 », Programming with Palermo, sur jeffreypalermo.com, (consulté le )
- (en) Suhas Chatekar, Learning NHibernate 4 : explore the full potential of NHibernate to build robust data access code, Packt Publishing, , 402 p. (ISBN 978-1-78439-206-2, OCLC 937787252, lire en ligne), p. 249-250
- (en) Robert C. Martin, « The Clean architecture - Clean Coder Blog », sur blog.cleancoder.com, (consulté le )
- (en) Robert C. Martin, Clean Architecture : A Craftsman's Guide to Software Structure and Design, Prentice Hall, , 404 p. (ISBN 978-0-13-449416-6, OCLC 1004983973, lire en ligne)
