Exemplos de infraestrutura em AWS - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Exemplos de infraestrutura em AWS

Esta seção fornece exemplos para projetar uma infraestrutura para seu aplicativo AWS que você pode usar para implementar uma arquitetura hexagonal. Recomendamos que você comece com uma arquitetura simples para criar um produto mínimo viável (MVP). A maioria dos microsserviços precisa de um único ponto de entrada para lidar com as solicitações do cliente, uma camada de computação para executar o código e uma camada de persistência para armazenar dados. Os AWS serviços a seguir são ótimos candidatos para uso como clientes, adaptadores primários e adaptadores secundários na arquitetura hexagonal:

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

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

  • Adaptadores secundários: Amazon DynamoDB, Amazon Relational Database Service (Amazon RDS), Amazon Aurora, API Gateway, Amazon SQS, Elastic Load Balancing EventBridge, Amazon Simple Notification Service (Amazon SNS)

As seções a seguir discutem esses serviços no contexto da arquitetura hexagonal com mais detalhes.

Comece de forma simples

Recomendamos que você comece de forma simples ao arquitetar um aplicativo usando a arquitetura hexagonal. Neste exemplo, o API Gateway é usado como cliente (API REST), o Lambda é usado como adaptador primário (computação) e o DynamoDB é usado como adaptador secundário (persistência). O cliente do gateway chama o ponto de entrada, que, nesse caso, é um manipulador Lambda.

Arquitetura hexagonal simples

Essa arquitetura é totalmente sem servidor e oferece ao arquiteto um bom ponto de partida. Recomendamos que você use o padrão de comando no domínio porque ele facilita a manutenção do código e se adapta aos novos requisitos comerciais e não funcionais. Essa arquitetura pode ser suficiente para criar microsserviços simples com algumas operações.

Aplique o padrão CQRS

Recomendamos que você mude para o padrão CQRS se o número de operações no domínio quiser aumentar. Você pode aplicar o padrão CQRS como uma arquitetura totalmente sem servidor AWS usando o exemplo a seguir.

Aplicação do padrão CQRS na arquitetura hexagonal

Este exemplo usa dois manipuladores Lambda, um para consultas e outro para comandos. As consultas são executadas de forma síncrona usando um gateway de API como cliente. Os comandos são executados de forma assíncrona usando o Amazon SQS como cliente.

Essa arquitetura inclui vários clientes (API Gateway e Amazon SQS) e vários adaptadores primários (Lambda), que são chamados por seus pontos de entrada correspondentes (manipuladores Lambda). Todos os componentes pertencem ao mesmo contexto limitado, portanto, estão dentro do mesmo domínio.

Evolua a arquitetura adicionando contêineres, um banco de dados relacional e uma API externa

Os contêineres são uma boa opção para tarefas de longa duração. Talvez você também queira usar um banco de dados relacional se tiver um esquema de dados predefinido e quiser se beneficiar do poder da linguagem SQL. Além disso, o domínio precisaria se comunicar com o externo APIs. Você pode desenvolver o exemplo de arquitetura para dar suporte a esses requisitos, conforme mostrado no diagrama a seguir.

Evoluindo a arquitetura hexagonal adicionando contêineres, um banco de dados relacional e uma API externa

Este exemplo usa o Amazon ECS como o adaptador principal para iniciar tarefas de longa execução no domínio. A Amazon EventBridge (cliente) inicia uma tarefa do Amazon ECS (ponto de entrada) quando um evento específico acontece. A arquitetura inclui o Amazon RDS como outro adaptador secundário para armazenar dados relacionais. Ele também adiciona outro gateway de API como adaptador secundário para invocar uma chamada de API externa. Como resultado, a arquitetura usa vários adaptadores primários e secundários que dependem de diferentes camadas de computação subjacentes em um domínio comercial.

O domínio está sempre fracamente acoplado a todos os adaptadores primários e secundários por meio de abstrações chamadas portas. O domínio define o que ele exige do mundo externo usando portas. Como é responsabilidade do adaptador implementar a porta, a mudança de um adaptador para outro não afeta o domínio. Por exemplo, você pode mudar do Amazon DynamoDB para o Amazon RDS escrevendo um novo adaptador, sem afetar o domínio.

Adicionar mais domínios (diminuir o zoom)

A arquitetura hexagonal se alinha bem aos princípios de uma arquitetura de microsserviços. Os exemplos de arquitetura mostrados até agora continham um único domínio (ou contexto limitado). Os aplicativos geralmente incluem vários domínios, que precisam se comunicar por meio de adaptadores primários e secundários. Cada domínio representa um microsserviço e está vagamente acoplado a outros domínios.

Adicionando domínios à sua arquitetura hexagonal

Nessa arquitetura, cada domínio usa um conjunto diferente de ambientes computacionais. (Cada domínio também pode ter vários ambientes computacionais, como no exemplo anterior.) Cada domínio define suas interfaces necessárias para se comunicar com outros domínios por meio de portas. As portas são implementadas usando adaptadores primários e secundários. Dessa forma, o domínio não será afetado se houver uma alteração no adaptador. Além disso, os domínios são desacoplados uns dos outros.

No exemplo de arquitetura mostrado no diagrama anterior, Lambda, Amazon, EC2 Amazon ECS e AWS Fargate são usados como adaptadores primários. O API Gateway, o Elastic Load Balancing e o Amazon SQS são usados como adaptadores secundários. EventBridge