Lorsque j’observe ces modèles, j’ai l’impression que les trois modèles essaient de défendre des idées similaires. Ils définissent tous un système testable faiblement couplé qui évite toute dépendance directe en termes de mise en œuvre, tout en utilisant leur propre terminologie et chacun avec des nuances spécifiques. Ils suggèrent tous des approches pour rendre les architectures logicielles plus gérables et testables, mais le font à leur manière.
Si nous les examinons tous ensemble, ils offrent des éléments architecturaux utiles qui s’appliquent quelle que soit l’approche de conception que vous choisissez d’utiliser. Nous les explorerons sous peu, mais examinons d’abord en quoi consistent chacun de ces modèles individuellement et comment ils se comparent les uns aux autres.
Par Rahul Garg
Architecture hexagonale
L’architecture hexagonale est parfois appelée architecture de ports et d’adaptateurs. Alistair Cockburn l’a introduit en 2005 , avec l’idée de base sous-jacente étant de rendre les applications indépendantes de la dépendance directe de l’interface utilisateur et de la base de données. Cette isolation est prise en charge par le concept de ports et d’adaptateurs.
Prenons un exemple. En tant que développeur, vous devez concevoir une logique métier liée à l’utilisateur, qui persistera dans une base de données. Vous voulez une isolation entre la logique métier et la persistance afin que les deux puissent fonctionner et évoluer dans leurs responsabilités principales.
- Une logique spécifique à la base de données sera encapsulée dans une classe d’adaptateur, par exemple, UserDataAdapter
- Classe de logique métier spécifique à l’utilisateur, telle que “Utilisateur”
- Un contrat entre User et UserDataAdapter afin qu’ils puissent interagir entre eux — par exemple : IUserDataPort. Ce contact est un port.
Comme l’explique Cockburn, le mot “hexagone” a été choisi non pas parce que le nombre six est important, mais plutôt pour permettre aux personnes qui conçoivent l’architecture d’avoir suffisamment d’espace pour insérer des ports et des adaptateurs selon les besoins, en s’assurant qu’ils ne sont pas contraints par un seul- dessin en couches dimensionnel.
Architecture en oignon
Jeffrey Palermo a introduit le concept d’ Onion Architecture en 2008. Il souhaitait développer une approche de conception pour des applications métier complexes en mettant l’accent sur la séparation des préoccupations dans l’ensemble du système. Ce modèle a franchi des étapes importantes au-delà de l’architecture hexagonale en élargissant l’idée de définir une couche métier centrale dans une application et les différentes couches qui l’entourent, de sorte que la couche centrale soit indépendante des couches externes et de leurs dépendances.
La couche centrale — le modèle de domaine — contient toutes les règles métier. Au niveau suivant se trouvent les services de domaine, qui sont comme des contrats de référentiels et d’autres dépendances. La couche la plus externe contient l’interface utilisateur et la connectivité à l’infrastructure externe.
En bref, la principale différence entre l’architecture en oignon et l’architecture hexagonale est que l’architecture en oignon introduit différentes couches, ainsi que la couche métier principale, dans l’application et déplace les connexions vers les dépendances externes telles que les bases de données et l’interface utilisateur vers le cercle extérieur. Cela signifie qu’ils peuvent être remplacés plus facilement si nécessaire.
Architecture épurée (Clean Architecture)
Robert Martin a introduit Clean Architecture en 2012. Les concepts de base sont similaires à Onion Architecture, mais sa terminologie est légèrement différente. Ici, le modèle de domaine est appelé une « entité ». L’entité contient des règles et une logique spécifiques à l’entreprise, tandis que la logique spécifique à l’opération d’application se trouve dans le cas d’utilisation. Ces cas d’utilisation orchestrent les opérations au-dessus des entités pour leur demander d’exécuter leurs règles métier afin d’atteindre les objectifs du cas d’utilisation.
À première vue, Clean Architecture offre une meilleure compréhension des limites et fournit une séparation plus claire des préoccupations par rapport à Onion Architecture. Ils sont très étroitement liés et défendent des idées similaires, mais avec des couches différentes. L’architecture propre explique clairement pourquoi chaque couche existe et quelles sont leurs responsabilités respectives. C’est pourquoi on l’appelle aussi l’architecture hurlante — elle rend tout explicite.
Que nous apprennent les modèles architecturaux ?
Comme nous l’avons vu, les trois styles architecturaux partagent les principes du couplage lâche et tentent de minimiser les pièces mobiles en superposant correctement l’application.
Quels sont donc les principaux enseignements que ces trois modèles nous offrent ? Quels principes architecturaux fondamentaux devons-nous garder à l’esprit ?
Règles métier centralisées
Mettre les règles spécifiques à l’entreprise dans un endroit centralisé est quelque chose suggéré à la fois par Clean et Onion Architecture. Bien qu’ils utilisent des noms différents pour des concepts très similaires, ils nous encouragent tous les deux à penser la logique métier de la même manière.
Règles spécifiques à l’application
Encore une fois, Clean et Onion Architecture pointent dans des directions similaires; ils suggèrent qu’il devrait y avoir une couche où vous gérez la logique spécifique à l’application à côté des règles d’entreprise.
Cette couche contiendra l’orchestration spécifique à l’opération et la logique associée pour l’application.
Règle de dépendance
Les trois modèles sont alignés sur ce principe; il souligne que les dépendances du code source ne doivent pointer que vers l’intérieur. La couche externe ne peut faire référence qu’à la couche interne et non l’inverse.
Isolation entre différentes couches
Les trois modèles préconisent fortement que les différentes parties de l’application doivent pouvoir se développer de manière isolée les unes avec les autres et qu’il doit y avoir une abstraction appropriée entre chaque couche de l’application.
Plus important encore, les règles métier de base doivent être indépendantes de :
Comment vous persistez:
- Votre choix de bases de données ne doit pas affecter le domaine principal
- Si vous changez le type de base de données, par exemple : SQL vers NoSQL, il ne devrait pas y avoir de changement dans votre logique métier.
- Les interactions entre le domaine et la persistance suivront une norme définie et seront indépendantes des détails de la persistance.
Comment vous l’exposez :
- La logique de l’interface utilisateur et les cas d’utilisation ne doivent jamais vous motiver à modifier le domaine principal.
- Que vous l’exposiez via JSON, XML ou GraphQL, le noyau ne devrait pas être affecté.
Quel framework tu utilises :
- Idéalement, le domaine principal devrait être indépendant du framework utilisé. Ce n’est peut-être pas très simple, mais cela peut être réalisé grâce à des abstractions prudentes.
- Par exemple,. si vous passez de Springboot à Micronaut en Java, de Zin à Martini en Golang, de WebAPI à Nancy en .NETCore, il ne devrait y avoir aucun changement en termes de définition du domaine principal.
Quelles sont vos dépendances externes :
- Le domaine principal ne doit pas être affecté par l’infrastructure et les dépendances associées. Par exemple, si vous utilisez AWS Kinesis et que vous devez le remplacer par des flux Kafka, le domaine principal ne devrait pas du tout être affecté.
- Les e-mails, SMS et événements sont quelques exemples de ces dépendances
Conclusion
Les modèles d’architecture sont au cœur de la conception de nos applications. Bien que nous puissions choisir différents modèles, en identifiant et en reconnaissant leurs similitudes, nous pouvons suivre certains principes fondamentaux qui fourniront une base solide pour concevoir une application critique pour l’entreprise. D’après mon expérience, la compréhension de ces règles m’a aidé à créer des systèmes logiciels extensibles, testables et complets.