Bonnes pratiques

Modélisez le domaine d'activité

Passez du domaine commercial à la conception du logiciel pour vous assurer que le logiciel que vous écrivez répond aux besoins de l'entreprise.

Utilisez des méthodologies de conception pilotée par domaine (DDD), telles que l'Event Storming, pour modéliser le domaine commercial. Event Storming propose un format d'atelier flexible. Au cours de l'atelier, des experts du domaine et des logiciels explorent la complexité du domaine commercial de manière collaborative. Les experts en logiciels utilisent les résultats de l'atelier pour démarrer le processus de conception et de développement des composants logiciels.

Rédiger et exécuter des tests dès le début

Utilisez le développement piloté par les tests (TDD) pour vérifier l'exactitude du logiciel que vous développez. Le TDD fonctionne mieux au niveau du test unitaire. Le développeur conçoit un composant logiciel en écrivant d'abord un test, qui invoque ce composant. Ce composant n'a aucune implémentation au début, donc le test échoue. À l'étape suivante, le développeur implémente les fonctionnalités du composant en utilisant des dispositifs de test avec des objets fictifs pour simuler le comportement des dépendances externes, ou ports. Lorsque le test réussit, le développeur peut continuer en implémentant de véritables adaptateurs. Cette approche améliore la qualité du logiciel et permet d'obtenir un code plus lisible, car les développeurs comprennent comment les utilisateurs utiliseraient les composants. L'architecture hexagonale soutient la méthodologie TDD en séparant le cœur de l'application. Les développeurs rédigent des tests unitaires qui se concentrent sur le comportement du cœur du domaine. Ils n'ont pas besoin d'écrire des adaptateurs complexes pour exécuter leurs tests ; ils peuvent utiliser de simples objets et accessoires fictifs.

Utilisez le développement piloté par le comportement (BDD) pour garantir end-to-end l'acceptation au niveau des fonctionnalités. Dans BDD, les développeurs définissent des scénarios pour les fonctionnalités et les vérifient auprès des parties prenantes de l'entreprise. Les tests BDD utilisent autant de langage naturel que possible pour y parvenir. L'architecture hexagonale soutient la méthodologie BDD avec son concept d'adaptateurs principaux et secondaires. Les développeurs peuvent créer des adaptateurs principaux et secondaires qui peuvent fonctionner localement sans faire appel à des services externes. Ils configurent la suite de tests BDD pour utiliser l'adaptateur principal local pour exécuter l'application.

Exécutez automatiquement chaque test dans le pipeline d'intégration continue pour évaluer en permanence la qualité du système.

Définir le comportement du domaine

Décomposez le domaine en entités, objets de valeur et agrégats (découvrez comment implémenter une conception axée sur le domaine) et définissez leur comportement. Implémentez le comportement du domaine afin que les tests écrits au début du projet réussissent. Définissez des commandes qui invoquent le comportement des objets du domaine. Définissez les événements que les objets du domaine émettent une fois qu'ils ont terminé un comportement.

Définissez les interfaces que les adaptateurs peuvent utiliser pour interagir avec le domaine.

Automatisez les tests et le déploiement

Après une première démonstration de faisabilité, nous vous recommandons de consacrer du temps à la mise en œuvre DevOps des pratiques. Par exemple, les pipelines d'intégration et de livraison continues (CI/CD) et les environnements de test dynamiques vous aident à maintenir la qualité du code et à éviter les erreurs lors du déploiement.

• Exécutez vos tests unitaires dans votre processus CI et testez votre code avant qu'il ne soit fusionné.

• Créez un processus sur CD pour déployer votre application dans un environnement de développement/test statique ou dans des environnements créés dynamiquement qui prennent en charge l'intégration et les end-to-end tests automatiques.

• Automatisez le processus de déploiement pour les environnements dédiés.

Faites évoluer votre produit en utilisant les microservices et le CQRS

Si votre produit est un succès, adaptez-le en décomposant votre projet logiciel en microservices. Tirez parti de la portabilité offerte par l'architecture hexagonale pour améliorer les performances. Divisez les services de requêtes et les gestionnaires de commandes en API synchrones et asynchrones distinctes. Envisagez d'adopter le modèle CQRS (Command Query Responsibility Ségrégation) et l'architecture pilotée par les événements.

Si vous recevez de nombreuses demandes de nouvelles fonctionnalités, envisagez de faire évoluer votre organisation en fonction des modèles DDD. Structurez vos équipes de manière à ce qu'elles possèdent une ou plusieurs fonctionnalités sous forme de contextes délimités, comme indiqué précédemment dans laÉvolutivité d'organisation section. Ces équipes peuvent ensuite mettre en œuvre la logique métier en utilisant une architecture hexagonale.

Concevez une structure de projet qui correspond aux concepts d'architecture hexagonale

L'infrastructure sous forme de code (IaC) est une pratique largement adoptée dans le développement du cloud. Il vous permet de définir et de gérer les ressources de votre infrastructure (telles que les réseaux, les équilibreurs de charge, les machines virtuelles et les passerelles) sous forme de code source. Ainsi, vous pouvez suivre toutes les modifications apportées à votre architecture à l'aide d'un système de contrôle de version. De plus, vous pouvez créer et déplacer facilement l'infrastructure à des fins de test. Nous vous recommandons de conserver le code de votre application et le code de votre infrastructure dans le même référentiel lorsque vous développez vos applications cloud. Cette approche facilite la maintenance de l'infrastructure de votre application.

Nous vous recommandons de diviser votre application en trois dossiers ou projets correspondant aux concepts de l'architecture hexagonale :entrypoints (adaptateurs principaux),domain (domaine et interfaces) etadapters (adaptateurs secondaires).

La structure de projet suivante fournit un exemple de cette approche lors de la conception d'une API surAWS. Le projet conserve le code de l'application (app) et le code de l'infrastructure (infra) dans le même référentiel, comme recommandé précédemment.

app/  # application code
|--- adapters/  # implementation of the ports defined in the domain
     |--- tests/  # adapter unit tests
|--- entrypoints/  # primary adapters, entry points
     |--- api/  # api entry point
          |--- model/  # api model
          |--- tests/  # end to end api tests
|--- domain/  # domain to implement business logic using hexagonal architecture
     |--- command_handlers/  # handlers used to run commands on the domain
     |--- commands/  # commands on the domain
     |--- events/  # events emitted by the domain
     |--- exceptions/  # exceptions defined on the domain
     |--- model/  # domain model
     |--- ports/  # abstractions used for external communication
     |--- tests/  # domain tests
infra/  # infrastructure code 

Comme indiqué précédemment, le domaine est le cœur de l'application et ne dépend d'aucun autre module. Nous vous recommandons de structurer ledomain dossier de manière à inclure les sous-dossiers suivants :

• command handlerscontient les méthodes ou les classes qui exécutent des commandes sur le domaine.

• commandscontient les objets de commande qui définissent les informations requises pour effectuer une opération sur le domaine.

• eventscontient les événements qui sont émis via le domaine puis acheminés vers d'autres microservices.

• exceptionscontient les erreurs connues définies dans le domaine.

• modelcontient les entités de domaine, les objets de valeur et les services de domaine.

• portscontient les abstractions par lesquelles le domaine communique avec les bases de données, les API ou d'autres composants externes.

• testscontient les méthodes de test (telles que les tests de logique métier) qui sont exécutées sur le domaine.

Les adaptateurs principaux sont les points d'entrée de l'application, tels que représentés par leentrypoints dossier. Cet exemple utilise leapi dossier comme adaptateur principal. Ce dossier contient une APImodel qui définit l'interface dont l'adaptateur principal a besoin pour communiquer avec les clients. Letests dossier contient des end-to-end tests pour l'API. Il s'agit de tests superficiels qui valident que les composants de l'application sont intégrés et fonctionnent en harmonie.

Les adaptateurs secondaires, tels que représentés par leadapters dossier, mettent en œuvre les intégrations externes requises par les ports de domaine. Un référentiel de base de données est un excellent exemple d'adaptateur secondaire. Lorsque le système de base de données change, vous pouvez écrire un nouvel adaptateur en utilisant l'implémentation définie par le domaine. Il n'est pas nécessaire de modifier le domaine ou la logique métier. Letests sous-dossier contient des tests d'intégration externes pour chaque adaptateur.