Nous devons comparer les trois architectures Hexagonal vs Onion vs Clean en nous basant sur quatre aspects :
- Découplage avec l’extérieur : Tout le code de domaine est indépendant du framework/bibliothèque.
- Direction des dépendances : Seule l’architecture Clean indique explicitement que la direction des dépendances est vers le centre, mais les architectures hexagonale et en oignon doivent également appliquer le principe d’inversion de dépendances.
- Couches : L’architecture hexagonale mentionne deux couches : la couche interne et la couche externe de l’application. L’architecture en oignon a quatre couches : Interfaces, Services d’application, Services de domaine et Modèle de domaine. L’architecture Clean est similaire à l’architecture en oignon : Interfaces, Services d’application, Services de domaine (cas d’utilisation) et Entités (Modèle de domaine).
- Testabilité en isolation : Dans les trois styles d’architecture, nous pouvons simplement simuler les outils externes et les mécanismes de livraison et tester le code de l’application de manière isolée, sans utiliser de base de données ni de requêtes HTTP.
Architecture en Oignon – Onion architecture
L’architecture en oignon a été proposée par Jeffrey Palermo en 2008.
L’architecture en oignon est similaire à l’architecture hexagonale. Elle externalise également l’infrastructure avec des interfaces appropriées pour assurer un découplage lâche entre l’application et l’externe. Elle décompose encore plus le domaine en plusieurs anneaux concentriques en utilisant l’inversion de contrôle.
Je vous laisse le soin de découvrir mon article sur cette architecture.
Architecture Clean – Clean Architecture
L’architecture propre proposée par Robert C. Martin en 2012.
L’architecture propre combine les principes de l’architecture hexagonale, de l’architecture en oignon et de plusieurs autres variantes. Ce modèle de conception fournit des niveaux supplémentaires de détails des composants, qui sont présentés sous forme d’anneaux concentriques.
Il isole les adaptateurs et les interfaces (interface utilisateur, bases de données, systèmes externes) dans les anneaux externes de l’architecture et laisse les anneaux internes pour les cas d’utilisation et les entités. Cette architecture utilise le principe d’inversion de dépendance avec la règle stricte que les dépendances ne doivent exister qu’entre un anneau externe et un anneau interne et jamais le contraire.
Architecture Hexagonale – Hexagonal Architecture
Alistair Cockburn en 2005 a inventé l’architecture Hexagonale qui s’appelle aussi architecture “Ports et Adaptateurs”. Elle sert à découpler la partie métier d’une application de ses services techniques. Ceci dans le but de préserver la partie métier pour qu’elle ne contienne que des éléments liés aux traitements fonctionnels.
L’interface entre la partie métier et l’extérieur se fait, d’une part, en utilisant les ports qui sont des interfaces définissant les entrées ou sorties et d’autre part, les adaptateurs qui sont des objets adaptant le monde extérieur à la partie métier.
Je vous laisse le soin de découvrir mon article sur cette architecture.
Conclusion
Le but est de structurer le code pour que les changements soient faciles, sûrs et rapides à effectuer. Avec l’isolation de la logique de domaine, le code est compréhensible.
Les activités de test sont beaucoup plus simples, car nous rédigeons d’abord que des tests pour sécuriser la logique métier, puis nous ajoutons des tests d’intégration pour couvrir l’enveloppe technique. Comme les tests servent de filet de sécurité, toute modification de la logique métier, voire toute modification de code technique, serait beaucoup moins complexe. Avec l’automatisation, nous pouvons effectuer des changements rapidement et en toute sécurité.
Et qui sait, un jour, nous pourrons peut-être simplement changer le framework qui enveloppe le code de la logique de domaine sans le code du domaine.
En fin de compte, il est important de noter que l’architecture logicielle n’est pas une fin en soi mais plutôt un moyen d’atteindre des objectifs spécifiques. Vous devez garder à l’esprit les besoins de l’entreprise et les contraintes du projet lors de la conception de l’architecture. Il ne peut y avoir réellement un Hexagonal vs Onion vs Clean car chaque approche a ses avantages et ses inconvénients. Il est important de choisir celle qui convient le mieux au contexte de votre projet.
En résumé, la conception d’une architecture logicielle solide et efficace est une étape cruciale dans le développement de logiciels de qualité. Que vous choisissiez une architecture hexagonale, en oignon ou propre, l’objectif est le même : isoler la logique métier de la logique technique pour faciliter la maintenance, les tests et les changements futurs.
