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.
Notes et 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)
