Création d'architectures hexagonales surAWS

Furkan Oruc, Dominik Goby, Darius Kunce et Michal Ploski, Amazon Web Services (AWS)

Juin 2022 (historique du document)

Ce guide décrit un modèle mental et un ensemble de modèles pour le développement d'architectures logicielles. Ces architectures sont faciles à maintenir, à étendre et à faire évoluer au sein de l'entreprise à mesure que l'adoption des produits augmente. Les hyperscalers cloud tels qu'Amazon Web Services (AWS) fournissent des éléments de base permettant aux petites et grandes entreprises d'innover et de créer de nouveaux produits logiciels. Le rythme rapide de l'introduction de ces nouveaux services et fonctionnalités amène les parties prenantes de l'entreprise à s'attendre à ce que leurs équipes de développement prototypent plus rapidement de nouveaux produits minimaux viables (MVP), afin que les nouvelles idées puissent être testées et vérifiées le plus rapidement possible. Souvent, ces MVP sont adoptés et font partie de l'écosystème logiciel d'entreprise. Lors de la production de ces MVP, les équipes abandonnent parfois les règles de développement logiciel et les meilleures pratiques, telles que les principes SOLID et les tests unitaires. Ils partent du principe que cette approche accélérera le développement et réduira les délais de mise sur le marché. Toutefois, s'ils ne parviennent pas à créer un modèle de base et un cadre pour l'architecture logicielle à tous les niveaux, il sera difficile, voire impossible, de développer de nouvelles fonctionnalités pour le produit. Le manque de certitude et l'évolution des exigences peuvent également ralentir l'équipe au cours du processus de développement.

Ce guide présente une architecture logicielle proposée, allant d'une architecture hexagonale de bas niveau à une décomposition architecturale et organisationnelle de haut niveau, qui utilise la conception pilotée par le domaine (DDD) pour relever ces défis. DDD permet de gérer la complexité de l'entreprise et de faire évoluer l'équipe d'ingénierie à mesure que de nouvelles fonctionnalités sont développées. Il aligne les parties prenantes commerciales et techniques sur les problèmes commerciaux, appelés domaines, en utilisant un langage omniprésent. L'architecture hexagonale est un facilitateur technique de cette approche dans un domaine très spécifique, appelé contexte limité. Un contexte délimité est un sous-domaine hautement cohésif et faiblement couplé du problème commercial. Nous vous recommandons d'adopter une architecture hexagonale pour tous vos projets logiciels d'entreprise, quelle que soit leur complexité.

L'architecture hexagonale encourage l'équipe d'ingénierie à résoudre d'abord le problème métier, tandis que l'architecture en couches classique détourne l'attention de l'ingénierie du domaine pour se concentrer d'abord sur la résolution des problèmes techniques. En outre, si les logiciels suivent une architecture hexagonale, il est plus facile d'adopter une approche de développement pilotée par les tests, ce qui réduit la boucle de rétroaction dont les développeurs ont besoin pour tester les exigences de l'entreprise. Enfin, l'utilisation de commandes et de gestionnaires de commandes permet d'appliquer les principes de responsabilité unique et d'ouverture/fermeture de SOLID. Le respect de ces principes produit une base de code que les développeurs et les architectes travaillant sur le projet peuvent facilement parcourir et comprendre, et réduit le risque d'introduire des modifications majeures dans les fonctionnalités existantes.

Ce guide s'adresse aux architectes logiciels et aux développeurs qui souhaitent comprendre les avantages de l'adoption de l'architecture hexagonale et du DDD pour leurs projets de développement logiciel. Il inclut un exemple de conception d'une infrastructure pour votre applicationAWS prenant en charge une architecture hexagonale. Pour un exemple d'implémentation, voir Structurer un projet Python selon une architecture hexagonale à l'aide duAWS Lambda site Web AWS Prescriptive Guidance.