Construire des architectures hexagonales sur AWS

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 de nouveaux produits minimalement viables (MVPs) plus rapidement, afin que les nouvelles idées puissent être testées et vérifiées dès que possible. Souvent, ceux-ci MVPs sont adoptés et font partie de l'écosystème logiciel d'entreprise. Lors de leur production MVPs, 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 supposent que cette approche accélérera le développement et réduira les délais de commercialisation. 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 pendant le processus de développement.

Ce guide décrit 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 axée sur le domaine (DDD) pour relever ces défis. DDD aide à gérer la complexité de l'entreprise et à 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 outil technique de cette approche dans un domaine très spécifique, appelé contexte limité. Un contexte limité est un sous-domaine très cohérent 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 commercial, tandis que l'architecture classique en couches 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 le logiciel suit une architecture hexagonale, il est plus facile d'adopter une approche de développement axée sur les tests, ce qui réduit la boucle de rétroaction dont les développeurs ont besoin pour tester les exigences commerciales. Enfin, l'utilisation de commandes et de gestionnaires de commandes est un moyen d'appliquer les principes de responsabilité unique et d'ouverture-fermeture de SOLID. Le respect de ces principes produit une base de code dans laquelle les développeurs et les architectes travaillant sur le projet peuvent facilement naviguer 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 application AWS prenant en charge une architecture hexagonale. Pour un exemple de mise en œuvre, consultez Structurer un projet Python en architecture hexagonale à l'aide du AWS Lambda site Web AWS Prescriptive Guidance.