Exemples d'infrastructures surAWS

Cette section fournit des exemples de conception d'une infrastructure pour votre applicationAWS 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. LesAWS 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, Elastic Load Balancing EventBridge, Amazon Simple Notification Service (Amazon SNS)

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

Commencez simplement

Nous vous recommandons de commencer simplement lorsque vous créez 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 totalement 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 cela facilite la maintenance du code et s'adapte aux nouvelles exigences commerciales et non fonctionnelles. Cette architecture pourrait être suffisante pour créer des microservices simples en quelques opérations.

Appliquer le modèle 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 enAWS 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 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 borné, ils se situent donc dans le 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 haleine. 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. En outre, le domaine devrait communiquer avec des API externes. Vous pouvez faire évoluer l'exemple d'architecture pour répondre à ces exigences, comme illustré dans le diagramme 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 de données relationnelles. Il ajoute également une autre passerelle 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 d'activité.

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 qu'il exige 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 s'aligne bien avec les principes d'une architecture de microservices. Les exemples d'architecture présentés jusqu'à présent contenaient un seul domaine (ou un contexte borné). 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 couplé de manière souple à d'autres domaines.

Dans cette architecture, chaque domaine utilise un ensemble différent d'environnements informatiques. (Chaque domaine peut également avoir plusieurs environnements de calcul, 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 mis en œuvre à 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 illustré dans le diagramme précédent, Lambda, Amazon EC2 et Amazon ECSAWS Fargate sont utilisés comme adaptateurs principaux. API Gateway, Elastic Load Balancing et Amazon SQS sont utilisés comme adaptateurs secondaires. EventBridge