# Projete a arquitetura de serviço da workload
Use uma arquitetura orientada a serviços (SOA) ou uma arquitetura de microsserviços para criar workloads altamente escaláveis e confiáveis. A arquitetura orientada a serviços (SOA) é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples.
As interfaces de arquitetura orientada a serviços (SOA) usam padrões de comunicação comuns para que possam ser rapidamente incorporadas a novas workloads. A SOA substituiu a prática de construção de arquiteturas monolíticas, que consistiam em unidades interdependentes e indivisíveis.
Na AWS, sempre usamos a SOA, mas agora adotamos a criação de nossos sistemas usando microsserviços. Embora os microsserviços tenham várias qualidades interessantes, o principal benefício para disponibilidade é que eles são menores e mais simples. Eles permitem diferenciar a disponibilidade exigida de diferentes serviços e, portanto, concentrar os investimentos mais especificamente nos microsserviços que têm as maiores necessidades de disponibilidade. Por exemplo, para entregar páginas de informações do produto em Amazon.com ("páginas de detalhes"), centenas de microsserviços são invocados para criar partes separadas da página. Embora haja alguns microsserviços que precisem estar disponíveis para fornecer o preço e os detalhes do produto, a grande maioria do conteúdo na página poderá simplesmente ser excluída se o serviço não estiver disponível. Mesmo itens como fotos e avaliações não são necessários para proporcionar uma experiência em que o cliente possa comprar um produto.
**Topics**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Escolher como segmentar a workload
A segmentação de workloads é importante ao determinar os requisitos de resiliência da sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos de sua aplicação, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de ser implantadas como microsserviços.
**Resultado desejado:** as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível.
Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para ajuste de escala a partir das necessidades iniciais. Ao refatorar um monólito existente, será necessário considerar o quanto a aplicação poderá oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada.
**Práticas comuns que devem ser evitadas:**
+ O [microsserviço *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito.
**Benefícios de estabelecer esta prática:**
+ Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade.
+ Redução do impacto das interrupções do serviço.
+ Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte.
+ Responsabilidades bem definidas para as equipes que oferecem suporte à workload.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA ou arquitetura de microsserviços (ou, em alguns casos, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, é necessário garantir que ela seja modular e tenha a capacidade de evoluir para SOA ou microsserviços à medida que o produto escala com a adoção do usuário. A SOA e os microsserviços oferecem, respectivamente, segmentação menor, que é preferida como uma arquitetura moderna escalável e confiável, mas há compensações a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços.
Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência.
![\[Diagrama de comparação entre arquiteturas monolítica, orientada a serviços e de microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Etapas de implementação
+ Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. A SOA e os microsserviços oferecem respectivamente segmentação menor, que é preferida por ser uma arquitetura moderna escalável e confiável. A SOA pode ser o meio-termo ideal para alcançar uma segmentação menor e também evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se sua workload aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais informações, consulte [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html).
+ Considere seguir o [padrão *Strangler Fig*](https://martinfowler.com/bliki/StranglerFigApplication.html) para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novos serviços e aplicações. O [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) atua como ponto de partida para a refatoração incremental. Para obter mais detalhes, consulte [Migração simplificada de workloads on-premises herdadas usando um padrão strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. O [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) pode ser usado com arquiteturas orientadas a serviços para fornecer descoberta e acesso confiáveis aos serviços. O [AWS Cloud Map](https://aws.amazon.com/cloud-map/) também pode ser usado para descoberta dinâmica de serviços baseada em DNS.
+ Se você estiver migrando de um monólito para SOA, o [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) poderá ajudar a preencher a lacuna como um barramento de serviço ao redesenhar aplicações herdadas na nuvem.
+ Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. A esta altura no processo de refatoração, escolha se deseja prosseguir com um banco de dados relacional ou não relacional (NoSQL). Para obter mais detalhes, consulte [Do SQL ao NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nível de esforço do plano de implementação:** Alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando a OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [O que é arquitetura orientada a serviços?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços: uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [O que é AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemplos relacionados:**
+ [Workshop Modernização iterativa de aplicações](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vídeos relacionados:**
+ [Como entregar excelência com microsserviços na AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos
A arquitetura orientada a serviços (SOA) define serviços com funções bem delineadas estabelecidas pelas necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto delimitado para traçar limites de serviço ao longo dos limites do contexto de negócios. O foco nos domínios de negócios e na funcionalidade ajuda as equipes a definir requisitos independentes de confiabilidade para seus serviços. Contextos delimitados isolam e encapsulam a lógica de negócios, permitindo que as equipes raciocinem melhor sobre como lidar com falhas.
**Resultado desejado:** em conjunto, engenheiros e partes interessadas do negócio definem contextos delimitados e os usam para projetar sistemas como serviços que cumprem funções empresariais específicas. Essas equipes usam práticas estabelecidas, como Event Storming, para definir os requisitos. As novas aplicações são projetadas como serviços, limites bem definidos e acoplamento fraco. Os monólitos existentes são decompostos em [contextos limitados](https://martinfowler.com/bliki/BoundedContext.html), e os projetos de sistemas migram para arquiteturas SOA ou de microsserviços. Quando os monólitos são refatorados, abordagens estabelecidas, como contextos de bolha e padrões de decomposição de monólitos, são aplicadas.
Os serviços orientados por domínios são executados como um ou mais processos que não compartilham o estado. Eles respondem de forma independente às flutuações na demanda e lidam com cenários de falha à luz dos requisitos específicos do domínio.
**Práticas comuns que devem ser evitadas:**
+ As equipes são formadas em torno de domínios técnicos específicos, como UI e UX, middleware ou banco de dados, em vez de domínios empresariais específicos.
+ As aplicações abrangem as responsabilidades do domínio. Serviços que abrangem contextos delimitados podem ser mais difíceis de manter, exigir maiores esforços de teste e que várias equipes de domínio participem das atualizações de software.
+ As dependências de domínio, como as bibliotecas de entidades de domínio, são compartilhadas entre serviços de uma forma que as alterações em um domínio de serviço exijam alterações em outros domínios de serviço.
+ Os contratos de serviço e a lógica de negócios não expressam entidades em uma linguagem de domínio comum e consistente, ocasionando camadas de tradução que complicam os sistemas e aumentam os esforços de depuração.
**Benefícios de implementar esta prática recomendada:** as aplicações são projetadas como serviços independentes delimitados por domínios de negócios e usam uma linguagem comercial comum. Os serviços podem ser testados e implantados de forma independente. Os serviços atendem aos requisitos de resiliência específicos do domínio implementado.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
O design orientado por domínio (DDD) é a abordagem fundamental para projetar e criar software em torno de domínios empresariais. É útil trabalhar com um framework existente ao criar serviços voltados para domínios empresariais. Ao trabalhar com aplicações monolíticas existentes, você pode utilizar os padrões de decomposição que fornecem técnicas estabelecidas para modernizar aplicações em serviços.
![\[Fluxograma descrevendo a abordagem do design orientado por domínio.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Etapas de implementação
+ As equipes podem realizar workshops de [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) a fim de identificar rapidamente eventos, comandos, agregados e domínios em um formato leve de notas adesivas.
+ Depois que as entidades e funções de domínio forem formadas em um contexto de domínio, você poderá dividir seu domínio em serviços usando [contexto limitado](https://martinfowler.com/bliki/BoundedContext.html) em que entidades que compartilham características e atributos semelhantes são agrupadas. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços.
+ Por exemplo, as entidades do site Amazon.com podem incluir pacote, entrega, cronograma, preço, desconto e moeda.
+ Pacote, entrega e cronograma são agrupados no contexto de envio, enquanto preço, desconto e moeda são agrupados no contexto de preços.
+ [A decomposição de monólitos em microsserviços](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) descreve padrões para refatorar microsserviços. O uso de padrões para decomposição por capacidade comercial, subdomínio ou transação se alinha bem às abordagens orientadas por domínio.
+ Técnicas táticas como o [contexto de bolha](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) permitem introduzir o DDD em aplicações existentes ou legadas sem reformulações antecipadas e compromissos totais com o DDD. Em uma abordagem de contexto de bolha, um pequeno contexto limitado é estabelecido usando um mapeamento e coordenação de serviços, ou [camada corrompimento](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), que protege o modelo de domínio recém-definido contra influências externas.
Depois que as equipes realizarem a análise de domínio e definirem entidades e contratos de serviço, elas podem utilizar os serviços da AWS para implementar o design orientado por domínio como serviços baseados em nuvem.
+ Comece o desenvolvimento definindo testes que simulem as regras de negócios do seu domínio. O desenvolvimento orientado por testes (TDD) e o desenvolvimento orientado por comportamento (BDD) ajudam as equipes a manter os serviços voltados para a solução de problemas de negócios.
+ Selecione os [serviços da AWS](https://aws.amazon.com/microservices/) que melhor atendem aos requisitos de domínio da sua empresa e à [arquitetura de microsserviços](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ A [tecnologia sem servidor da AWS](https://aws.amazon.com/serverless/) permite que sua equipe enfoque a lógica de domínio específica em vez de gerenciar servidores e infraestrutura.
+ Os [contêineres na AWS](https://aws.amazon.com/containers/) simplificam o gerenciamento de sua infraestrutura para que você possa enfocar nos requisitos de domínio.
+ Os [bancos de dados com propósito específico](https://aws.amazon.com/products/databases/) ajudam você a adequar seus requisitos de domínio ao tipo de banco de dados mais adequado.
+ [Criar arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) descreve uma framework para criar lógica de negócios em serviços que funcionam retroativamente a partir de um domínio empresarial para atender aos requisitos funcionais e, depois, conectar adaptadores de integração. Os padrões que separam os detalhes da interface da lógica de negócios com serviços da AWS ajudam as equipes a enfocar na funcionalidade do domínio e melhorar a qualidade do software.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)
**Documentos relacionados:**
+ [Microsserviços da AWS](https://aws.amazon.com/microservices/)
+ [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Como dividir um monólito em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Design orientado por domínio: como lidar com a complexidade no núcleo do software](https://www.amazon.com/gp/product/0321125215)
+ [Criação de arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [Decompor monólitos em microsserviços](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [Mensagens entre contextos delimitados](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [Microsserviços](https://www.martinfowler.com/articles/microservices.html)
+ [Desenvolvimento orientado por testes](https://en.wikipedia.org/wiki/Test-driven_development)
+ [Desenvolvimento orientado por comportamento](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Exemplos relacionados:**
+ [Como projetar microsserviços nativos da nuvem na AWS (do DDD/EventStormingWorkshop)](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Ferramentas relacionadas:**
+ [Bancos de dados na Nuvem AWS](https://aws.amazon.com/products/databases/)
+ [Tecnologia sem servidor na AWS](https://aws.amazon.com/serverless/)
+ [Contêineres na AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Fornecer contratos de serviço por API
Os contratos de serviço são acordos documentados entre produtores e consumidores de API estabelecidos em uma definição de API legível por máquina. Uma estratégia de versionamento de contrato permite que os consumidores continuem usando a API existente e migrem suas aplicações para uma API mais recente quando estiverem prontos. A implantação do produtor pode acontecer a qualquer momento, desde que o contrato seja cumprido. A equipe de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API.
**Resultado desejado:** as aplicações criadas com arquiteturas orientadas a serviços ou de microsserviços podem operar de forma independente e, ao mesmo tempo, ter uma dependência de tempo de execução integrada. As alterações implantadas em um consumidor ou produtor de API não interrompem a estabilidade do sistema geral quando os dois lados seguem um contrato de API comum. Os componentes que se comunicam por meio de APIs de serviço podem realizar lançamentos funcionais independentes, atualizações para dependências de runtime ou fazer failover em um site de recuperação de desastres (DR) com pouco ou nenhum impacto entre si. Além disso, serviços diferentes são capazes de escalar de forma independente a absorção da demanda de recursos sem exigir que outros serviços escalem simultaneamente.
**Práticas comuns que devem ser evitadas:**
+ Criação de APIs de serviço sem esquemas altamente tipificados. Isso resulta em APIs que não podem ser usadas para gerar vinculações de API e payloads que não podem ser validadas de maneira programática.
+ Não adotar uma estratégia de versionamento, o que força os consumidores de API a atualizarem e lançarem ou falharem com a evolução dos contratos de serviço.
+ Mensagens de erro que vazam detalhes da implementação do serviço subjacente em vez de descreverem falhas de integração no contexto e no idioma do domínio.
+ Não usar contratos de API para desenvolver casos de teste e simular implementações de API para permitir testes independentes dos componentes do serviço.
**Benefícios de implementar esta prática recomendada:** sistemas distribuídos compostos por componentes que se comunicam por meio de contratos de serviço de API podem aumentar a confiabilidade. Os desenvolvedores podem detectar possíveis problemas no início do processo de desenvolvimento com a verificação de tipo durante a compilação a fim de verificar se as solicitações e as respostas seguem o contrato da API e se os campos obrigatórios estão presentes. Os contratos de API oferecem uma interface clara de autodocumentação de APIs e oferecem melhor interoperabilidade entre diferentes sistemas e linguagens de programação.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Depois de identificar os domínios de negócios e determinar a segmentação da workload, você pode desenvolver suas APIs de serviço. Primeiro, defina contratos de serviço legíveis por máquina para APIs e, depois, implemente uma estratégia de versionamento de API. Quando estiver pronto para integrar serviços em protocolos comuns, como REST, GraphQL ou eventos assíncronos, você poderá incorporar serviços da AWS à sua arquitetura para integrar seus componentes com contratos de API altamente tipificados.
**Serviços da AWS para contratos de API de serviços**
Incorpore serviços da AWS, incluindo o [Amazon API Gateway](https://aws.amazon.com/api-gateway/), o [AWS AppSync](https://aws.amazon.com/appsync/) e o [Amazon EventBridge](https://aws.amazon.com/eventbridge/), em sua arquitetura para usar contratos de serviços de API em sua aplicação. O Amazon API Gateway ajuda você a se integrar diretamente com serviços da AWS nativos e outros serviços Web. O API Gateway é compatível com a [especificação da OpenAPI](https://github.com/OAI/OpenAPI-Specification) e versionamento. O AWS AppSync é um endpoint gerenciado do [GraphQL](https://graphql.org/) que você configura definindo um esquema do GraphQL para definir uma interface de serviço para consultas, mutações e assinaturas. O Amazon EventBridge usa esquemas de eventos para definir eventos e gerar vinculações de código para seus eventos.
## Etapas de implementação
+ Primeiro, defina um contrato para sua API. Um contrato expressará os recursos de uma API, bem como definirá objetos e campos de dados altamente tipificados para a entrada e a saída da API.
+ Ao configurar APIs no API Gateway, você pode importar e exportar especificações da OpenAPI para seus endpoints.
+ [Importar uma definição da OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifica a criação de sua API e pode ser integrada a ferramentas de infraestrutura como código da AWS, como o [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) e o [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/).
+ [Exportar uma definição de API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifica a integração a ferramentas de teste de API e oferece ao consumidor de serviços uma especificação de integração.
+ Você pode definir e gerenciar as APIs do GraphQL com o AWS AppSync [definindo um arquivo de esquema do GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) para gerar sua interface de contrato e simplificar a interação com modelos REST complexos, várias tabelas de banco de dados ou serviços legados.
+ Os projetos do [AWS Amplify](https://aws.amazon.com/amplify/) integrados ao AWS AppSync geram arquivos de consulta JavaScript altamente tipificados para uso em sua aplicação, bem como uma biblioteca cliente do AWS AppSync GraphQL para tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/).
+ Quando você consome eventos de serviço do Amazon EventBridge, eles seguem os esquemas já existentes no registro do esquema ou os definidos com a especificação da OpenAPI. Com um esquema definido no registro, também é possível gerar vinculações de cliente a partir do contrato de esquema para integrar seu código aos eventos.
+ Estender ou realizar o versionamento de sua API. Estender uma API é uma opção mais simples ao adicionar campos que podem ser configurados com campos opcionais ou valores padrão para campos obrigatórios.
+ Contratos baseados em JSON para protocolos, como REST e GraphQL, podem ser uma boa opção para a extensão do contrato.
+ Contratos baseados em XML para protocolos, como SOAP, devem ser testados com consumidores de serviços para determinar a viabilidade da extensão do contrato.
+ Ao realizar o versionamento de uma API, considere implementar o controle de versão por procuração em que uma fachada é usada para oferecer compatibilidade com versões para que a lógica possa ser mantida em uma única base de código.
+ Com o API Gateway, você pode usar [mapeamentos de solicitação e resposta](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) para simplificar a absorção de alterações no contrato estabelecendo uma fachada para fornecer valores padrão para novos campos ou para retirar os campos removidos de uma solicitação ou resposta. Com essa abordagem, o serviço subjacente pode manter uma única base de código.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Controlar e limitar chamadas de novas tentativas](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
**Documentos relacionados:**
+ [O que é uma API (interface de programação de aplicações)?](https://aws.amazon.com/what-is/api/)
+ [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços: uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [Trabalhar com extensões do API Gateway para OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [Especificação da OpenAPI](https://github.com/OAI/OpenAPI-Specification)
+ [GraphQL: esquemas e tipos](https://graphql.org/learn/schema/)
+ [Vinculações de código do Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Exemplos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando a OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Amazon API Gateway para a aplicação CRUD do Amazon DynamoDB usando a OpenAPI](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Padrões modernos de integração de aplicações em uma era sem servidor: integração do serviço do API Gateway](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [Implementar o versionamento do API Gateway baseado em cabeçalho com o Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: como criar uma aplicação cliente](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Vídeos relacionados:**
+ [Usar OpenAPI na AWS SAM para gerenciar o API Gateway](https://www.youtube.com/watch?v=fet3bh0QA80)
**Ferramentas relacionadas:**
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)