urbanisation-si.com

L'architecture hexagonale (ou encore Ports & Adapters Architecture, ce qui est moins sexy) créée par Alistair Cockburn garantit la réutilisabilité de la logique métier, en la rendant agnostique techniquement.

(Diagramme de Composants UML pour l'illustration de l'Architecture Hexagonale, réalisé avec l’outil commercial Enterprise Architect de Sparx Systems https://sparxsystems.com/ Les composants du domaine implémentent les interfaces des API métiers et utilisent les interfaces des SPI de persistance).

Présentation

Chris Richardson, dans son article (en anglais) Jfokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices, explique les pictogrammes métaphoriques utilisés pour marketer les sujets qu'il aborde. Dans la pseudo science des logos, l’hexagone symbolise le travail, la rigueur, l’effort collectif, le réseau, la structure sociale et enfin l'organisation.

Avec UML ou ArchiMate, point d'élément de modélisation hexagonal ! Une vue d'artiste assez commune, montrant l'hexagone, se trouve à la fin de cet article.   

Le domaine est isolé du monde extérieur par l'intermédiaire d'API (Application Programming Interface) et de SPI (Service Provider Interface) qui sont représentées par des interfaces.

Seulement deux mondes existent : à l'intérieur, toute la logique métier et à l'extérieur, l'infrastructure technique.

Les dépendances vont toujours de l'extérieur vers l'intérieur de l'hexagone. 

L'implémentation du domaine métier est indépendante de tous les autres aspects techniques comme la présentation, la gestion des protocoles de communication, les flux de messages, les moyens de persistance des entités métier, y compris des frameworks intrusifs obligeant à inclure du code technique.

Un corollaire de ceci est que le domaine métier ne dépend que de lui-même. 

Description

Un concept clé de cette architecture est donc de mettre toute la logique métier dans un seul endroit nommé le domaine (hexagone), qui ne dépend que de lui-même ; c'est le seul moyen de s'assurer que la logique métier est découplée des couches techniques. 

On y parvient en utilisant l'inversion du contrôle correspondant au "D (Dependency Inversion Principle)" des principes connus sous le nom de “SOLID” de Robert C. Martin ou Uncle Bob (voir son article en anglais : Solid Relevance), base de l’orienté objet, mais aussi de l’organisation structurelle de l’urbanisation des SI.

A noter que certains praticiens ont théorisé d’autres recommandations spécifiques aux microservices, comme celles de Paulo Merson, voir son article (en anglais) : Principles for Microservice Design: Think IDEALS, Rather than SOLID.

Bon nombre d'entreprises intègrent l'hexagone dans leurs logos pour symboliser l'organisation et le travail comme une ruche d'abeilles. 

Puisque les problèmes d'intégration sont traités à part, la testabilité du domaine métier est augmentée. 

De vrais tests fonctionnels sont enfin possibles grâce à cette contrainte de l'Architecture Hexagonale, car ils vont interagir directement avec le domaine métier et uniquement avec lui.

L'extérieur de l'hexagone (l'infrastructure) est divisé en deux parties virtuelles, le côté gauche et le côté droit :

• A gauche, se trouve tout ce qui va interroger le domaine (le contrôleur, les couches REST, Event Streaming, Batch Launcher, etc.),
• A droite, tout ce qui va fournir des informations/services au domaine (couche de persistance SQL ou NoSQL, services tiers, etc.).

Pour laisser l'extérieur interagir avec le domaine, le domaine propose des interfaces ou ports divisés en deux catégories :

• L'API fournit toutes les interfaces pour tout ce qui doit interroger le domaine. Ces interfaces sont implémentées à l’intérieur du domaine,
• Le SPI regroupe toutes les interfaces requises par le domaine pour récupérer des informations auprès de tiers. Ces interfaces sont utilisées dans l'hexagone et implémentées par la partie droite de l'infrastructure. 

L'API et le SPI font partie de l'Hexagone. L'API et le SPI ne manipulent que les objets métier du domaine de l'Hexagone. Ils assurent en effet l'isolement.

Dans une architecture en couches, l'objet métier ou le service crée généralement les DAO (Data Access Object). Dans l'architecture hexagonale, le domaine ne gère que les objets de domaine. Par conséquent, la persistance se charge de traduire les objets du domaine en « DAO » à persister et utilise pour cela des adaptateurs. 

Modèle UML

Dans le diagramme UML de composants ci-dessus, l'API et le SPI sont les ports ; les modules d'infrastructure, qui les implémentent ou les utilisent, sont les adaptateurs, d'où l'autre appellation plus technique de Ports & Adapters Architecture.

Pour cette raison, nous pensons que le langage de modélisation le plus approprié pour l'architecture Hexagonale est la norme UML, avec le diagramme de composants permettant visuellement de mieux représenter les connexions entre les ports (prises) correspondant aux interfaces fournies et ceux correspondants aux interfaces requises.

Modèle ArchiMate

(Modèle ArchiMate réalisé avec l’outil open source Archi de Phil Beauvoir et Jean-Baptiste Sarrodie de l’Open Group ArchiMate Forum https://www.archimatetool.com/)

Changer les technologies n'a aucun impact sur le code du domaine. Cette architecture est parfaitement conforme à la méthode de conception DDD (Domain Driven Design) abordée dans notre article Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design).

Intérêts

L'avantage majeur que présente cette architecture vient de sa modularité. Parce que tout est découplé, une couche REST et l'Event Streaming peuvent coexister simultanément sans aucun impact sur le domaine métier.

Du côté SPI, une migration de SQL vers NoSQL est grandement facilitée. Étant donné que le SPI ne changera pas parce qu'on modifie la méthode de persistance, le reste de l'application ne sera pas affecté. 

Limites

Toutefois, l'architecture hexagonale ne convient pas systématiquement à toutes les situations. De la même manière que pour le Domain Driven Design, elle ne s'applique réellement qu'à un domaine métier consistant. Il est déconseillé de la mettre en œuvre pour une application transformant juste des données dans un autre format, par exemple.

Exceptions

Le domaine doit être complètement exempt de toutes technologies, sauf, et c’est l’exception qui confirme la règle, celles qui auraient un très faible impact sur le domaine métier, par exemple un gestionnaire de logs et de traces, comme indiqué dans notre article sur le DDD (Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design)).

Méthode de conception

Une équipe de développeurs (la “two-pizza team” popularisée par Jeff Bezos) doit : 

• Commencer par l'intérieur de l'hexagone,
• Se concentrer sur la fonctionnalité, plutôt que sur les détails techniques,
• Retarder les choix sur la mise en œuvre technique. Parfois, il est difficile de savoir de quelle implémentation technique on a besoin au début. Par conséquent, retarder ce choix aide à se concentrer sur ce qui apporte de la valeur à l’entreprise : la fonctionnalité.
  De plus, après la mise en place de la logique métier, de nouveaux éléments peuvent aider à faire le meilleur choix concernant l’infrastructure.
  Cela garantit que l'hexagone est autonome et qu’il est auto-testé avec de vrais tests fonctionnels centrés sur le métier uniquement. Ces tests appellent directement l'API du domaine en évitant toute perturbation de la partie technique. Un adaptateur est créé, simulant le contrôleur pour tester les fonctionnalités du domaine.

Conclusion

Le réel avantage à découpler la logique métier du code technique, c’est de garantir que le domaine d'activité est durable et robuste, face à l'évolution continue de la technologie.

En résumé, les caractéristiques de l'Architecture Hexagonale :

• Mettre toute la logique métier en un seul endroit,
• Le domaine est isolé et agnostique sur la partie technique, car il ne dépend que de lui-même,
• Les dépendances vont toujours de l'extérieur vers l'intérieur de l'Hexagone,
• L'Hexagone est un module autonome. Ainsi, il augmente la testabilité du domaine en écrivant de vrais tests fonctionnels qui n'ont pas à traiter de problèmes techniques,
• Cette architecture offre une modularité puissante. Il aide à écrire autant d'adaptateurs que nécessaire avec un faible impact sur le reste du logiciel. Et comme le domaine est indépendant des technologies, elles peuvent être modifiées sans aucun impact sur l'entreprise,
• En commençant toujours par le domaine, les développeurs assurent d'apporter de la valeur au client en se concentrant sur le développement des fonctionnalités. De cette façon, ils peuvent retarder les choix de mise en œuvre technique, pour faire le meilleur choix au bon moment.

Et pour terminer, voici à mon avis la meilleure vue d'artiste, issue de l'Open Group (https://publications.opengroup.org/), désolée Alistair et Chris.

“Aimer savoir est humain, savoir aimer est divin”

Joseph Roux

Compléments de lecture

• L’Architecture Micro-Services expliquée à ma fille
  
  
• Inconvénients de l'Architecture Micro-Services
  
  
• Orchestration des micro-services avec BPMN
  
  
• Conseils pour réussir vos micro-services et éviter qu’ils ne se transforment en véritable pensum
  
  
• Estimation de la complexité d’une Architecture Micro-Services
  
  
• Solutions sur étagère pour la gestion des défaillances des Micro-Services
  
  
• Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?
  
  
• Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design)