Exemples d'infrastructure sur AWS

Cette section fournit des exemples de conception d'une infrastructure pour votre application AWS que vous pouvez utiliser pour implémenter une architecture hexagonale. Nous vous recommandons de commencer par une architecture simple pour créer un produit minimum viable (MVP). La plupart des microservices ont besoin d'un point d'entrée unique pour traiter les demandes des clients, d'une couche de calcul pour exécuter le code et d'une couche de persistance pour stocker les données. Les AWS services suivants sont d'excellents candidats pour une utilisation en tant que clients, adaptateurs principaux et adaptateurs secondaires dans une architecture hexagonale :

• Clients : Amazon API Gateway, Amazon Simple Queue Service (Amazon SQS), Elastic Load Balancing, Amazon EventBridge

• Adaptateurs principaux : AWS Lambda Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon) EC2

• Adaptateurs secondaires : Amazon DynamoDB, Amazon Relational Database Service (Amazon RDS), Amazon Aurora, API Gateway, Amazon SQS, EventBridge Elastic Load Balancing, Amazon Simple Notification Service (Amazon SNS)

Les sections suivantes traitent plus en détail de ces services dans le contexte de l'architecture hexagonale.

Commencez simplement

Nous vous recommandons de commencer simplement lorsque vous concevez une application en utilisant une architecture hexagonale. Dans cet exemple, API Gateway est utilisé comme client (API REST), Lambda est utilisé comme adaptateur principal (calcul) et DynamoDB est utilisé comme adaptateur secondaire (persistance). Le client de passerelle appelle le point d'entrée, qui, dans ce cas, est un gestionnaire Lambda.

Cette architecture est entièrement sans serveur et constitue un bon point de départ pour l'architecte. Nous vous recommandons d'utiliser le modèle de commande dans le domaine, car il facilite la maintenance du code et s'adapte aux nouvelles exigences commerciales et non fonctionnelles. Cette architecture peut être suffisante pour créer des microservices simples avec quelques opérations.

Appliquez le motif CQRS

Nous vous recommandons de passer au modèle CQRS si le nombre d'opérations sur le domaine doit augmenter. Vous pouvez appliquer le modèle CQRS en tant qu'architecture entièrement sans serveur en AWS utilisant l'exemple suivant.

Cet exemple utilise deux gestionnaires Lambda, l'un pour les requêtes et l'autre pour les commandes. Les requêtes sont exécutées de manière synchrone en utilisant une passerelle d'API comme client. Les commandes sont exécutées de manière asynchrone en utilisant Amazon SQS comme client.

Cette architecture inclut plusieurs clients (API Gateway et Amazon SQS) et plusieurs adaptateurs principaux (Lambda), qui sont appelés par leurs points d'entrée correspondants (gestionnaires Lambda). Tous les composants appartiennent au même contexte délimité, ils appartiennent donc au même domaine.

Faites évoluer l'architecture en ajoutant des conteneurs, une base de données relationnelle et une API externe

Les conteneurs sont une bonne option pour les tâches de longue durée. Vous pouvez également utiliser une base de données relationnelle si vous disposez d'un schéma de données prédéfini et souhaitez bénéficier de la puissance du langage SQL. De plus, le domaine devrait communiquer avec des tiers APIs. Vous pouvez faire évoluer l'exemple d'architecture pour répondre à ces exigences, comme indiqué dans le schéma suivant.

Cet exemple utilise Amazon ECS comme adaptateur principal pour lancer des tâches de longue durée dans le domaine. Amazon EventBridge (client) lance une tâche Amazon ECS (point d'entrée) lorsqu'un événement spécifique se produit. L'architecture inclut Amazon RDS comme autre adaptateur secondaire pour le stockage des données relationnelles. Il ajoute également une autre passerelle d'API en tant qu'adaptateur secondaire pour appeler un appel d'API externe. Par conséquent, l'architecture utilise plusieurs adaptateurs principaux et secondaires qui s'appuient sur différentes couches de calcul sous-jacentes dans un même domaine métier.

Le domaine est toujours couplé de manière souple à tous les adaptateurs principaux et secondaires par le biais d'abstractions appelées ports. Le domaine définit ce dont il a besoin du monde extérieur en utilisant des ports. Comme il incombe à l'adaptateur d'implémenter le port, le passage d'un adaptateur à un autre n'affecte pas le domaine. Par exemple, vous pouvez passer d'Amazon DynamoDB à Amazon RDS en écrivant un nouvel adaptateur, sans affecter le domaine.

Ajouter d'autres domaines (zoom arrière)

L'architecture hexagonale correspond parfaitement aux principes d'une architecture de microservices. Les exemples d'architecture présentés jusqu'à présent contenaient un seul domaine (ou un contexte limité). Les applications incluent généralement plusieurs domaines, qui doivent communiquer via des adaptateurs principaux et secondaires. Chaque domaine représente un microservice et est vaguement couplé à d'autres domaines.

Dans cette architecture, chaque domaine utilise un ensemble différent d'environnements informatiques. (Chaque domaine peut également avoir plusieurs environnements informatiques, comme dans l'exemple précédent.) Chaque domaine définit ses interfaces requises pour communiquer avec d'autres domaines via des ports. Les ports sont implémentés à l'aide d'adaptateurs principaux et secondaires. Ainsi, le domaine n'est pas affecté en cas de modification de l'adaptateur. De plus, les domaines sont découplés les uns des autres.

Dans l'exemple d'architecture présenté dans le schéma précédent, Lambda, Amazon, EC2 Amazon ECS AWS Fargate sont utilisés comme adaptateurs principaux. API Gateway, Elastic Load Balancing et Amazon SQS sont utilisés comme adaptateurs secondaires. EventBridge