RETOUR
Découvrez la capacité de l'architecture hexagonale à améliorer la maintenabilité, la testabilité et l'adaptabilité des logiciels.
Dans ce guide complet, nous nous pencherons sur les nuances de Architecture hexagonaleNous examinerons sa définition, ses composantes et son histoire. Nous établirons des comparaisons entre Architecture hexagonale et d'autres modèles architecturaux populaires afin de mettre en évidence ses atouts uniques. Nous examinerons également son rôle essentiel dans la conception pilotée par le domaine (DDD) et les microservices, qui sont de plus en plus importants dans le monde de l'architecture moderne. développement de logiciels.
Dans le paysage dynamique des architecture logicielle, Architecture hexagonaleégalement connu sous le nom de Ports et Modèle d'adaptateursL'Union européenne s'est imposée comme un concurrent redoutable, remettant progressivement en question les normes de l'Union européenne en matière de droits de l'homme. l'architecture traditionnelle en couches.
La nécessité d'une conception architecturale permettant de faciliter les tests et d'améliorer la maintenabilité a été à l'origine de ce projet, Architecture hexagonale a été conçu. Sa mission : fournir des applications logicielles sans se soucier des complexités et de l'inconstance du monde extérieur.
Au cours de cet article, nous nous embarquerons dans un voyage à travers les annales de l'Union européenne. Architecture hexagonale - une architecture qui se situe au carrefour de la simplicité et de la puissance. Nous retracerons son histoire, sa structure et ses principes, et nous la comparerons à d'autres architectures. modèles architecturaux. Nous examinerons son potentiel pour élever la qualité des applications logicielles et réduire la marée montante de la dette technique qui déconcerte l'industrie du logiciel.
En son cœur, Architecture hexagonaleou les Ports et Architecture des adaptateursest un modèle de conception fondé sur la séparation des préoccupations. Il divise une application en deux parties principales : l'intérieur et l'extérieur.
L'intérieur, également appelé "cœur de l'application", abrite les éléments suivants logique d'entreprise et les objets du domaine - le noyau de valeur de votre logiciel. Ce sanctuaire intérieur reste détaché des influences extérieures, ce qui permet de préserver l'intégrité du logiciel. logique d'entreprise et le modèle de domaine.
L'extérieur, quant à lui, est le domaine des systèmes externes - de la interface utilisateur à l'accès à la base de données - qui interagissent avec le cœur de l'application. Ces interactions sont gérées par un mécanisme de ports et d'adaptateurs, ce qui garantit une séparation nette entre le noyau de l'application et la base de données. cœur de l'application et ses acteurs extérieurs.
Architecture hexagonale est une idée d'Alistair Cockburn, un visionnaire qui a d'abord articulé ce concept comme une réponse aux limites des systèmes traditionnels d'information et de communication. architecture en couches. Il a été conçu pour créer un système de gestion de l'information qui soit indépendant de la technologie. couche de domaine qui isole le noyau logique d'entreprise des influences extérieures, telles que la interface utilisateur code et l'accès aux bases de données.
Dans le domaine traditionnel architecture en couchesEn effet, les modifications apportées à une couche pouvaient se répercuter sur d'autres couches, entraînant des conséquences inattendues. En outre, les tests étaient compliqués par les dépendances complexes entre les couches.
Architecture hexagonale est apparu comme une solution, offrant un modèle dans lequel les changements dans une partie du système ne déstabiliseraient pas les autres parties. En substance, il s'agissait de faire en sorte que le système ne soit pas déstabilisé par des changements dans une partie du système. logique d'entreprise indépendamment du fait que l'on y accède par une interface web, un API RESTou même un ligne de commande.
Architecture hexagonaleLe système de gestion de l'information, qui doit son nom à l'illusion hexagonale qu'il donne dans les représentations diagrammatiques, comprend trois éléments principaux : le modèle de domaine, les ports (primaires et secondaires) et les adaptateurs (primaires et secondaires).
Les modèle de domaine est le cœur de l'application logicielle, encapsulant l'ensemble des éléments de l'application. règles de gestion et la logique de base. Les objets du domaine résidant dans ce modèle contiennent des valeurs et des règles commerciales spécifiques.
Ensuite, nous avons les ports, les conduits entre les modèle de domaine et le monde extérieur. Ports primaires exposent l'interface de l'application logique d'entrepriseIls servent de passerelle vers le cœur de l'application. Ils représentent les cas d'utilisation pris en charge par l'application.
Ports secondairesD'autre part, les interfaces sont tournées vers l'extérieur. Ils décrivent les interfaces dont l'application a besoin dans le monde extérieur, comme les couches de persistance ou les services externes.
Enfin, nous avons les adaptateurs, qui agissent comme des traducteurs entre le modèle de domaine et le monde extérieur. Ils convertissent les données du format utilisé par les systèmes externes au format utilisé par le logique d'entrepriseet vice versa.
Ports et adaptateurs constituent la passerelle entre les cœur de l'application et les acteurs externes. Les ports primaires représentent les cas d'utilisation de l'application, permettant aux acteurs externes d'interagir avec l'application. Considérez-les comme les interfaces de service de votre couche métier.
Les ports secondaires, quant à eux, sont des interfaces requises par votre application depuis le monde extérieur. Il peut s'agir de services tels que l'accès aux bases de données, les services web ou même les services temporels. Ils exposent ce dont l'application a besoin, indépendamment de toute technologie ou caractéristique propre à un fournisseur.
Les adaptateurs sont les manifestations physiques de ces ports. Ils traduisent les données du format utilisé par l logique d'entreprise au format utilisé par les acteurs externes et vice versa. Ces adaptateurs peuvent être des convertisseurs d'adaptateurs spécifiques à une technologie pour les API REST, les bases de données SQL ou les systèmes de messagerie, mais il peut également s'agir de scripts de traitement par lots ou de systèmes de messagerie. interface utilisateur code. Les adaptateurs forment la frontière de l'application, ce qui permet à cette dernière d'être agnostique sur le plan technologique.
Les ports primaires représentent les opérations que notre application peut effectuer - les commandes que notre domaine principal peut accepter. Ils sont souvent mis en œuvre sous forme d'interfaces dans des langages tels que Javaqui définit les opérations offertes par l'application.Adaptateurs primairessont donc les implémentations de ces interfaces pour des acteurs externes spécifiques.
En revanche, les ports secondaires sont des interfaces que le domaine principal utilise pour interagir avec le monde extérieur. Il peut s'agir d'interfaces permettant de conserver les objets du domaine ou d'envoyer des notifications. Adaptateurs secondaires sont les implémentations réelles de ces interfaces - une Base de données SQL ou un adaptateur de notification par courrier électronique, par exemple.
Ensemble, les ports et adaptateurs primaires et secondaires forment une frontière flexible et modulaire autour de l'application, en séparant les éléments suivants logique de domaine des préoccupations techniques. Ils assurent une séparation nette des responsabilités et permettent aux différentes parties du système d'évoluer de manière indépendante.
La règle de dépendance est un principe fondamental dans Architecture hexagonale qui stipule que les dépendances doivent être orientées vers le cœur de l'application. Le cœur de l'application ne dépend pas d'une base de données particulière, d'une interface utilisateur ou de tout autre organisme externe.
Ce principe est étroitement lié à la Principe d'inversion de la dépendance (DIP), l'un des principes SOLID de la conception orientée objet. Le DIP stipule que les modules de haut niveau (logique d'entreprise ou couche de domaine ne doit pas dépendre de modules de bas niveau (comme l'adaptateur de base de données). Au contraire, les deux doivent dépendre d'abstractions. Cette inversion des dépendances permet aux modules de haut niveau d'être isolés des modifications apportées aux modules de bas niveau, ce qui favorise une conception dans laquelle l'adaptateur de base de données et l'adaptateur de base de données ne dépendent pas l'un de l'autre. logique d'entreprise est à l'origine de l'architecture globale.
La cartographie est un processus essentiel dans Architecture hexagonaleoù un adaptateur spécifique à la technologie convertit les données du format utilisé par l systèmes externes dans un format que notre couche de domaine peut comprendre. Ce mappage facilite la traduction entre les représentations internes et externes des données de l'application.
Par exemple, lorsqu'une requête HTTP arrive dans notre application à partir d'une interface externe telle qu'un API RESTDans le cas d'une application, les données de la demande doivent être traduites de JSON en objets de domaine utilisables par l'application. Cette traduction relève de la responsabilité des adaptateurs.
Inversement, lorsque l'application doit envoyer une réponse, les adaptateurs reconvertissent les objets du domaine en JSON. Cela permet à l'application principale d'ignorer les spécificités du monde extérieur tout en garantissant qu'elle peut interpréter correctement les données entrantes et formater les données sortantes.
Architecture hexagonale offre une multitude d'avantages, qui peuvent être largement attribués au découplage des applications logicielles de leurs éléments externes et à la délimitation claire entre les différentes parties d'un système.
L'un des avantages fondamentaux est la séparation des préoccupations, qui favorise la maintenabilité et la lisibilité du code. Le découplage du noyau logique d'entreprise de la monde extérieur permet de modifier les adaptateurs, les bases de données et les systèmes d'information propres à chaque technologie. les interfaces utilisateurs sans modifier le noyau logique d'entreprise.
Architecture hexagonale excelle également dans le domaine de la testabilité. L'isolation des dépendances externes de l'architecture permet aux développeurs d'exécuter des tests de régression automatisés et d'écrire des tests d'évaluation de la performance. les suites de tests automatisés plus facilement. Cette isolation renforce la résilience de l'application, car les modifications apportées à un composant n'auront pas d'effets néfastes sur les autres.
En outre, l'architecture prend en charge plusieurs adaptateurs pour le même port, ce qui ouvre la porte à plusieurs adaptateurs pour le même port secondaire. Cette flexibilité permet à l'application d'interagir avec différents types de bases de données ou de prendre en charge différents types d'applications. interface utilisateur plates-formes.
Dans le domaine du développement de logiciels, la maintenabilité est souvent une caractéristique recherchée, mais c'est une caractéristique que les styles architecturaux traditionnels peuvent avoir du mal à offrir. Architecture hexagonale se distingue ici par l'importance qu'il accorde à la maintenabilité.
En se concentrant sur la séparation des préoccupations, Architecture hexagonale garantit que les modifications apportées à une partie de l'application ne se répercutent pas sur les autres parties. Cette caractéristique permet de réduire le temps et les efforts consacrés à la compréhension et au débogage du code.
En outre, l'architecture encourage la réutilisation du code en favorisant une conception où le noyau logique d'entreprise est isolée des technologies spécifiques utilisées pour piloter l'application. Ce découplage permet aux développeurs d'échanger, de mettre à jour ou de remanier les systèmes d'information. interfaces externes sans affecter la logique de base, ce qui réduit le risque d'introduction de bogues.
La dette technique, une préoccupation importante dans le développement de logiciels, fait référence au coût futur de la refonte et de la correction des raccourcis et des piratages dans le code. Architecture hexagonale offre une approche proactive de la réduction de cette dette.
En facilitant une séparation claire entre le noyau logique d'entreprise et composants externes, Architecture hexagonale réduit la probabilité d'un code entrelacé qui peut causer des problèmes de maintenance et aggraver la dette technique. La maintenabilité et la testabilité inhérentes à l'architecture jouent également un rôle dans la réduction de la dette technique, car elles permettent d'éviter l'introduction de bogues et facilitent les efforts de remaniement.
En outre, la capacité des Architecture hexagonale pour prendre en charge les changements dans l'infrastructure sans nécessiter de changements dans le système de gestion de l'information. logique d'entreprise fournit un tampon de protection contre la dette technique. Cette capacité permet aux équipes de s'adapter aux changements d'exigences ou de technologies sans avoir à réécrire de grandes parties de l'application.
En pratique, Architecture hexagonale apporte une approche structurée au développement de logiciels. La frontière hexagonale autour de l'application principale permet de délimiter clairement où se termine l'application et où se trouve le logiciel. monde extérieur commence.
Les adaptateurs agissent comme des gardiens, traduisant les demandes des acteurs externes dans une forme que l'application principale peut comprendre, et vice versa. Ce faisant, ils veillent à ce que l'application principale reste indifférente aux spécificités du monde extérieur, qu'il s'agisse d'une base de données, d'un système d'exploitation ou d'un système d'information. API externeou un interface utilisateur.
La conception pilotée par le domaine (DDD) est une méthodologie de développement de logiciels qui donne la priorité aux concepts fondamentaux de l'entreprise, ou à la conception pilotée par le domaine. logique de domaineCette méthodologie s'aligne remarquablement bien sur les principes de l'architecture et de l'urbanisme. Cette méthodologie s'aligne remarquablement bien sur celle de l Architecture hexagonalequi souligne également l'importance de la logique d'entreprise et le modèle de domaine dans l'architecture.
Dans le cadre de Architecture hexagonaleLe DDD garantit que les modules de haut niveau de l'application - les couches du domaine - sont indépendants des éléments externes tels que le système d'information de l'entreprise. interface utilisateur ou la base de données. Cette indépendance est assurée par les ports et les adaptateurs, qui protègent la couche domaine des spécificités de la base de données. systèmes externes, permettant ainsi à l logique de domaine d'évoluer de manière indépendante.
En outre, Architecture hexagonale complète les principes de conception stratégique de DDD, y compris le concept de contextes délimités. Chaque contexte délimité dans DDD peut être considéré comme un hexagone en Architecture hexagonale, avec le modèle de domaine en son centre et l ports et adaptateurs qui font office de limites.
Les microservices, un autre style d'architecture contemporain, peuvent bénéficier grandement des avantages suivants Architecture hexagonale. La nature décentralisée des microservices - où chaque service encapsule une capacité commerciale spécifique - s'aligne parfaitement sur l'encapsulation de l'information. logique d'entreprise au cœur de l'hexagone.
Tout comme chaque microservice doit être couplé de manière souple avec les autres, chaque hexagone de l Architecture hexagonale est également isolé des autres, ne communiquant qu'à travers les ports et adaptateurs définis. Cela permet à chaque microservice d'avoir son propre architecture hexagonaleIl en résulte une collection de services autonomes et faiblement couplés.
L'isolation fournie par Architecture hexagonale peut être particulièrement utile lorsqu'il s'agit de gérer la complexité et la nature distribuée des microservices. En isolant les logique commerciale de base du monde extérieur, Architecture hexagonale assure la logique d'entreprise reste intacte, quels que soient les changements apportés à d'autres services ou systèmes externes.
La façon dont un logiciel est conçu peut avoir un impact profond sur son évolution dans le temps. En comparant Architecture hexagonale à d'autres architectures nous permet de mieux comprendre ses points forts et les compromis possibles.
Architecture en couches est un produit traditionnel modèle architectural qui structure une application en couches logiques - souvent des couches de présentation, d'activité et d'accès aux données. Le principal inconvénient de ce modèle est qu'il encourage une forte dépendance entre les couches, ce qui conduit à une situation où les changements dans une couche peuvent se répercuter sur l'ensemble de l'application.
En revanche, Architecture hexagonale minimise ces dépendances. Au lieu de couches, il dispose d'un cœur de l'application entouré d'adaptateurs interchangeables. Les modifications apportées à un serveur de base de données, par exemple, n'affectent que l'adaptateur correspondant, ce qui laisse l'adaptateur de base de données en place. cœur de l'application et d'autres adaptateurs.
Architecture propre, un autre modèle architecturalElle présente de nombreuses similitudes avec Architecture hexagonale. Ils mettent tous deux l'accent sur la séparation des préoccupations, visent à isoler le cœur du problème et à le résoudre. règles de gestion des détails extérieurs, et adhérer à la Principe d'inversion de la dépendance.
Cependant, Architecture hexagonale se concentre davantage sur la façon dont l'application interagit avec le à l'extérieur à l'aide de ports et d'adaptateurs, tandis que les Architecture propre fournit une structure plus détaillée pour les couches internes de l'architecture. En d'autres termes, Architecture propre peut être considéré comme un surensemble de Architecture hexagonaleavec des conseils supplémentaires sur l'organisation de la structure interne de l'application.
Architecture en oignon est un autre style d'architecture qui vise à isoler les logique commerciale de base de la interfaces externes et l'infrastructure. Il comporte plusieurs couches concentriques avec le modèle de domaine au centre, et chaque couche ne peut dépendre que des couches qui la composent.
Bien qu'elles partagent un objectif commun, les entreprises Hexagonal et Architecture en oignon Les méthodes employées pour y parvenir sont légèrement différentes. Architecture en oignon met l'accent sur la direction des dépendances, en veillant à ce que toutes les dépendances aillent vers l'intérieur. Architecture hexagonaletout en approuvant également les dépendances tournées vers l'intérieur, met davantage l'accent sur l'interaction avec le système d'information de l monde extérieur par l'intermédiaire de ses ports et adaptateurs.
L'un des principaux atouts de la Architecture hexagonale est l'accent mis sur la testabilité. En isolant l'application principale de l monde extérieur par l'intermédiaire de ports et d'adaptateurs, l'architecture hexagonale permet l'exécution d'une série de tâches. tests automatisés qui peut donner confiance dans la stabilité et l'exactitude du logiciel.
Dans un Architecture hexagonale, le ports primairesqui encapsulent l'essentiel de la règles de gestionLes bases de données peuvent être testées indépendamment du monde extérieur. Par exemple, au lieu de communiquer avec une base de données réelle pendant les tests, une base de données de adaptateur de base de données peut être remplacé par un double de test qui simule le comportement d'une base de données réelle. Cela permet aux développeurs de se concentrer sur le test de la règles de gestionplutôt que l'interaction avec la base de données.
En outre, tests de régression automatisés peuvent être facilement construits pour valider que le système se comporte comme prévu lorsque des changements sont apportés. Ce niveau de testabilité est un avantage significatif lorsqu'il s'agit de maintenir et de mettre à jour un logiciel, car il permet de détecter et de corriger les problèmes à un stade précoce du processus de développement.
En outre, la structure des Architecture hexagonale prend également en charge les tests d'intégration. En remplaçant le composants externes (comme un serveur de base de données ou un API externe) avec des doubles de test, les développeurs peuvent tester la façon dont le cœur de l'application s'intègre à ces composants sans qu'il soit nécessaire d'utiliser les systèmes externes proprement dits. Cela peut considérablement améliorer la rapidité et la fiabilité des tests.
Architecture hexagonale apparaît comme une solution séduisante dans la vaste étendue des stratégies de développement de logiciels. Elle se distingue par le découplage des cœur de l'application de l'environnement externe, garantissant ainsi un haut degré de maintenabilité, de testabilité et de flexibilité. Cette séparation permet aux développeurs de se concentrer sur le cœur du système. logique d'entreprisetout en renforçant la résilience du logiciel contre les altérations de l'environnement. systèmes externes.
Bien que l'architecture hexagonale présente des inconvénients, la multitude d'avantages qu'elle offre en fait un atout précieux dans la boîte à outils de tout développeur. Dans le domaine de la architecture logicielleLe modèle hexagonal continue d'affirmer sa suprématie.
Cet article, émaillé de exemples de codeL'objectif est d'offrir une compréhension approfondie de l'économie et de l'environnement. Architecture hexagonale et ses avantages potentiels. Gardez à l'esprit que le secret d'une architecture efficace ne réside pas dans l'adhésion aveugle à des modèles, mais dans la compréhension des principes sous-jacents et leur mise en œuvre réfléchie pour répondre à des exigences spécifiques.
Dans le domaine de l'architecture hexagonale, l'interface définie entre le couche application et le couche de données est d'une importance capitale. Que vous soyez un architecte logiciel Qu'il s'agisse d'une personne qui envisage d'adopter cette méthodologie ou d'un développeur qui s'efforce de comprendre ses complexités, il est clair que l'influence de cette architecture ne cesse de croître. Elle démontre les différentes façons dont elle peut être utilisée efficacement. Par exemple, dans un banque application, le interface du référentiel peut jouer le rôle d'adaptateur secondaire, en établissant un pont entre le cœur de l'application avec code externe. Cette séparation permet d'échanger les mise en œuvre concrète d'un système de fichiers ou d'une technologie spécifique, sans avoir d'impact sur les services d'application.
Les développement équipe peut maintenant travailler sur le côté gauche de l'application sans se préoccuper des les facteurs externeset ainsi garantir une progression sans heurts. C'est ainsi que nous concluons notre exploration du monde des Architecture hexagonaleun style architectural qui continue d'étendre son influence dans le paysage du développement de logiciels.
French 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
Arabic 
Italian 
Japanese 
Korean 
Polish