Qualité dès le design - AWS Conseils prescriptifs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Qualité dès le design

L'adoption d'une architecture hexagonale permet de promouvoir la qualité de votre base de code dès le début de votre projet. Il est important de mettre en place un processus qui vous aide à répondre aux exigences de qualité attendues dès le départ, sans ralentir le processus de développement.

Changements localisés et meilleure lisibilité

L'utilisation de l'approche d'architecture hexagonale permet aux développeurs de modifier le code d'une classe ou d'un composant sans affecter les autres classes ou composants. Cette conception favorise la cohésion des composants développés. En dissociant le domaine des adaptateurs et en utilisant des interfaces connues, vous pouvez améliorer la lisibilité du code. Il devient plus facile d'identifier les problèmes et les cas critiques.

Cette approche facilite également la révision du code pendant le développement et limite l'introduction de modifications non détectées ou de dettes techniques.

Tester d'abord la logique métier

Les tests locaux peuvent être réalisés en introduisant end-to-end, en intégrant et en effectuant des tests unitaires dans le projet. nd-to-end Les tests E couvrent l'ensemble du cycle de vie des demandes entrantes. Ils invoquent généralement un point d'entrée d'application et testent pour voir si elle répond aux exigences de l'entreprise. Chaque projet logiciel doit comporter au moins un scénario de test utilisant des entrées connues et produisant les résultats attendus. Cependant, l'ajout de scénarios supplémentaires peut s'avérer complexe, car chaque test doit être configuré pour envoyer une demande via un point d'entrée (par exemple, via une API REST ou des files d'attente), passer par tous les points d'intégration requis par l'action métier, puis valider le résultat. La configuration de l'environnement pour le scénario de test et l'affirmation des résultats peuvent prendre beaucoup de temps pour les développeurs.

Dans l'architecture hexagonale, vous testez la logique métier de manière isolée et vous utilisez des tests d'intégration pour tester les adaptateurs secondaires. Vous pouvez utiliser des adaptateurs fictifs ou faux dans vos tests de logique métier. Vous pouvez également combiner les tests pour les cas d'utilisation professionnelle avec des tests unitaires pour votre modèle de domaine afin de maintenir une couverture élevée avec un faible couplage. Il est recommandé que les tests d'intégration ne valident pas la logique métier. Ils doivent plutôt vérifier que l'adaptateur secondaire appelle correctement les services externes.

Idéalement, vous pouvez utiliser le développement piloté par les tests (TDD) et commencer à définir des entités de domaine ou des cas d'utilisation commerciaux avec des tests appropriés dès le début du développement. La rédaction des tests vous permet d'abord de créer des implémentations fictives des interfaces requises par le domaine. Lorsque les tests sont réussis et que les règles de logique du domaine sont satisfaites, vous pouvez implémenter les adaptateurs réels et déployer le logiciel dans l'environnement de test. À ce stade, votre implémentation de la logique de domaine n'est peut-être pas idéale. Vous pouvez ensuite refactoriser l'architecture existante pour la faire évoluer en introduisant des modèles de conception ou en réorganisant le code en général. En utilisant cette approche, vous pouvez éviter d'introduire des bogues de régression et améliorer l'architecture au fur et à mesure de la croissance du projet. En combinant cette approche avec les tests automatiques que vous exécutez dans le cadre de votre processus d'intégration continue, vous pouvez réduire le nombre de bogues potentiels avant qu'ils ne soient mis en production.

Si vous utilisez des déploiements sans serveur, vous pouvez rapidement provisionner une instance de l'application dans votreAWS compte pour une intégration et end-to-end des tests manuels. Après ces étapes de mise en œuvre, nous vous recommandons d'automatiser les tests à chaque nouvelle modification apportée au référentiel.

Maintenabilité

La maintenabilité fait référence à l'exploitation et à la surveillance d'une application afin de s'assurer qu'elle répond à toutes les exigences et de minimiser la probabilité d'une défaillance du système. Pour rendre le système opérationnel, vous devez l'adapter au trafic future ou aux exigences opérationnelles. Vous devez également vous assurer qu'il est disponible et facile à déployer avec un impact minimal ou nul sur les clients.

Pour comprendre l'état actuel et historique de votre système, vous devez le rendre observable. Vous pouvez le faire en fournissant des mesures, des journaux et des traces spécifiques que les opérateurs peuvent utiliser pour s'assurer que le système fonctionne comme prévu et pour suivre les bogues. Ces mécanismes devraient également permettre aux opérateurs d'effectuer une analyse des causes profondes sans avoir à se connecter à la machine et à lire le code.

Une architecture hexagonale vise à augmenter la maintenabilité de vos applications Web afin que votre code nécessite globalement moins de travail. En séparant les modules, en localisant les modifications et en dissociant la logique métier des applications de la mise en œuvre des adaptateurs, vous pouvez produire des métriques et des journaux qui aident les opérateurs à mieux comprendre le système et à comprendre l'étendue des modifications spécifiques apportées aux adaptateurs principaux ou secondaires.