Architecture hexagonale

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].

Exemple d'architecture hexagonale

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.

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].

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.

• Patron d'architecture
• Architecture logicielle
• Diagramme de structure composite
• Analyse et conception orientée objet
• Architecture en couches