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á.
# Padrões para decomposição de monólitos
Depois de decidir decompor um monólito em seu portfólio de aplicativos, você deve escolher os padrões de decomposição apropriados e introduzi-los em sua organização.
**nota**
Você pode usar vários padrões para decompor um monólito. Por exemplo, você pode decompor um monólito por [capacidade comercial](decompose-business-capability.md) e, em seguida, usar o [padrão de subdomínio](decompose-subdomain.md) para detalhá-lo mais.
**Topics**
+ [Decompor por capacidade comercial](decompose-business-capability.md)
+ [Decompor por subdomínio](decompose-subdomain.md)
+ [Decompor por transações](decompose-transactions.md)
+ [Padrão de serviço por equipe](service-per-team.md)
+ [padrão strangler fig](strangler-fig.md)
+ [Padrão de ramificação por abstração](branch-by-abstraction.md)
# Decompor por capacidade comercial
Você pode usar o processo ou os recursos de negócios da sua organização para decompor um monólito. Uma *capacidade de negócios* é o que uma empresa faz para gerar valor (por exemplo, vendas, atendimento ao cliente ou marketing). Normalmente, uma organização tem várias capacidades de negócios e elas variam de acordo com o setor ou setor. Use esse padrão se sua equipe tiver informações suficientes sobre as unidades de negócios da sua organização e você tiver especialistas no assunto (SMEs) para cada unidade de negócios. A tabela a seguir explica as vantagens e desvantagens de usar esse padrão.
****
| Vantagens | Desvantagens |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) |
No diagrama a seguir, um monólito de seguros é decomposto em quatro microsserviços com base nas capacidades comerciais.
![\[Decomposição de monólitos de acordo com as capacidades de negócios\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-business-capability.png)
# Decompor por subdomínio
Esse padrão usa um subdomínio de [design controlado por domínio (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design) para decompor monólitos. Essa abordagem divide o modelo de domínio da organização em subdomínios separados que são rotulados como *principais* (um diferencial importante para a empresa), de *suporte* (possivelmente relacionados aos negócios, mas não um diferencial) ou *genéricos* (não específicos do negócio). Esse padrão é apropriado para sistemas monolíticos existentes que têm limites bem definidos entre os módulos relacionados ao subdomínio. Isso significa que você pode decompor o monólito reempacotando os módulos existentes como microsserviços, mas sem reescrever significativamente o código existente. Cada subdomínio tem um modelo, e o escopo desse modelo é chamado de contexto *limitado*. Os microsserviços são desenvolvidos em torno desse contexto limitado. A tabela a seguir explica as vantagens e desvantagens de usar esse padrão.
****
| Vantagens | Desvantagens |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) |
A ilustração a seguir mostra como um monólito de seguros pode ser decomposto em subdomínios depois de ser decomposto pelas capacidades comerciais.
![\[Decomposição de monólitos por subdomínios\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png)
A ilustração mostra que os serviços de *vendas* e *marketing* são divididos em microsserviços menores. Os modelos de *compras* e *reclamações* são importantes diferenciais comerciais para *vendas* e são divididos em dois microsserviços separados. O *marketing* é decomposto pelo uso de funcionalidades comerciais de suporte, como *campanhas*, *análises* e *relatórios*.
# Decompor por transações
Em um sistema distribuído, um aplicativo normalmente precisa chamar vários microsserviços para concluir uma transação comercial. Para evitar problemas de latência ou problemas de confirmação em duas fases, você pode agrupar seus microsserviços com base nas transações. Esse padrão é apropriado se você considera os tempos de resposta importantes e seus diferentes módulos não criam um monólito depois de empacotá-los. A tabela a seguir explica as vantagens e desvantagens de usar esse padrão.
****
| Vantagens | Desvantagens |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |
Na ilustração a seguir, o monólito de seguros é dividido em vários microsserviços com base nas transações.
![\[Decomposição de monólitos por meio de transações\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)
Em um sistema de seguro, uma solicitação de reclamação geralmente é marcada para um cliente após o envio. Isso significa que um serviço de reclamações não pode existir sem um microsserviço de *clientes*. *Vendas* e *clientes* são agrupados em um pacote de microsserviços, e uma transação comercial requer coordenação com ambos.
# Padrão de serviço por equipe
Em vez de decompor monólitos por recursos ou serviços de negócios, o padrão de serviço por equipe os divide em microsserviços gerenciados por equipes individuais. Cada equipe é responsável por uma capacidade comercial e possui a base de código da capacidade. A equipe desenvolve, testa, implanta ou escala seus serviços de forma independente e interage principalmente com outras equipes para negociar. APIs Recomendamos que você atribua cada microsserviço a uma única equipe. No entanto, se a equipe for grande o suficiente, várias subequipes poderão possuir microsserviços separados dentro da mesma estrutura de equipe. A tabela a seguir explica as vantagens e desvantagens de usar esse padrão.
****
| Vantagens | Desvantagens |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) |
A ilustração a seguir mostra como um monólito pode ser dividido em microsserviços que são gerenciados, mantidos e fornecidos por equipes individuais.
![\[Decompor monólitos em microsserviços por equipes\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/service-per-team.png)
# padrão strangler fig
Os padrões de design discutidos até agora neste guia se aplicam a aplicações de decomposição para projetos novos. E quanto aos projetos abandonados que envolvem aplicações grandes e monolíticas? Aplicar os padrões de design anteriores a eles será difícil, porque dividi-los em partes menores enquanto estão sendo usados ativamente é uma grande tarefa.
O [padrão de figueira estranguladora](https://martinfowler.com/bliki/StranglerFigApplication.html) é um padrão de design popular introduzido por Martin Fowler, que se inspirou em um certo tipo de figo que se semeia nos galhos superiores das árvores. A árvore existente inicialmente se torna uma estrutura de suporte para a nova figueira. A figueira então envia suas raízes para o solo, envolvendo gradualmente a árvore original e deixando apenas a figueira nova e autoportante em seu lugar.
Esse padrão é comumente usado para transformar incrementalmente um aplicativo monolítico em microsserviços, substituindo uma funcionalidade específica por um novo serviço. O objetivo é que o legado e as versões novas e modernizadas coexistam. O novo sistema é inicialmente suportado e encapsulado pelo sistema existente. Esse suporte dá ao novo sistema tempo para crescer e potencialmente substituir totalmente o sistema antigo.
O processo de transição de um aplicativo monolítico para microsserviços implementando o padrão strangler fig consiste em três etapas: transformar, coexistir e eliminar:
+ *Transformar* — identifique e crie componentes modernizados transferindo-os ou reescrevendo-os paralelamente ao aplicativo legado.
+ *Coexistir* — mantenha o aplicativo monolítico para reversão. Intercepte chamadas externas do sistema incorporando um proxy HTTP (por exemplo, [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)) no perímetro do seu monólito e redirecione o tráfego para a versão modernizada. Isso ajuda você a implementar a funcionalidade de forma incremental.
+ *Elimine* — retire a funcionalidade antiga do monólito à medida que o tráfego é redirecionado do monólito antigo para o serviço modernizado.
A tabela a seguir explica as vantagens e desvantagens de usar o padrão de figo estrangulador.
****
| Vantagens | Desvantagens |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) |
A ilustração a seguir mostra como um monólito pode ser dividido em microsserviços aplicando o padrão strangler fig a uma arquitetura de aplicativo. Ambos os sistemas funcionam paralelamente, mas você começará a mover a funcionalidade para fora da base de código monolítico e a aprimorará com novos recursos. Esses novos recursos oferecem a oportunidade de arquitetar microsserviços da maneira que melhor atenda às suas necessidades. Você continuará retirando recursos do monólito até que tudo seja substituído por microsserviços. Nesse ponto, você pode eliminar o aplicativo monolítico. O ponto principal a ser observado aqui é que tanto o monólito quanto os microsserviços viverão juntos por um período de tempo.
![\[Decompor monólitos em microsserviços usando o padrão strangler fig\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)
# Padrão de ramificação por abstração
O padrão de figo estrangulador funciona bem quando você pode interceptar as chamadas no perímetro do monólito. No entanto, se você quiser modernizar componentes que existem mais profundamente na pilha de aplicativos legados e têm dependências ascendentes, recomendamos o padrão branch by abstraction. Esse padrão permite que você faça alterações na base de código existente para permitir que a versão modernizada coexista com segurança com a versão antiga sem causar interrupções.
Para usar o padrão de ramificação por abstração com sucesso, siga este processo:
1. Identifique componentes monolíticos que tenham dependências iniciais.
1. Crie uma camada de abstração que represente as interações entre o código a ser modernizado e seus clientes.
1. Quando a abstração estiver pronta, altere os clientes existentes para usar a nova abstração.
1. Crie uma nova implementação da abstração com a funcionalidade reformulada fora do monólito.
1. Mude a abstração para a nova implementação quando estiver pronto.
1. Quando a nova implementação fornecer todas as funcionalidades necessárias aos usuários e o monólito não estiver mais em uso, limpe a implementação antiga.
O padrão de ramificação por abstração geralmente é confundido com [alternâncias de recursos](http://martinfowler.com/bliki/FeatureToggle.html), que também permitem que você faça alterações no sistema de forma incremental. A diferença é que as alternâncias de recursos têm como objetivo permitir o desenvolvimento de novos recursos e mantê-los invisíveis para os usuários quando o sistema está em execução. Portanto, as alternâncias de recursos são usadas no momento da implantação ou no tempo de execução para escolher se um determinado recurso ou conjunto de recursos está visível no aplicativo. Branch by abstraction é uma técnica de desenvolvimento e pode ser combinada com alternâncias de recursos para alternar entre a implementação antiga e a nova.
A tabela a seguir explica as vantagens e desvantagens de usar o padrão de ramificação por abstração.
****
| Vantagens | Desvantagens |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) |
A ilustração a seguir mostra o padrão de ramificação por abstração de um componente de *Notificação* no monólito de seguros. Começa criando um resumo ou uma interface para a funcionalidade de notificação. Em pequenos incrementos, os clientes existentes são alterados para usar a nova abstração. Isso pode exigir a pesquisa na base de código de chamadas APIs relacionadas ao componente *Notificação*. Você cria a nova implementação da funcionalidade de notificação como um microsserviço fora do seu monólito e a hospeda na arquitetura modernizada. Dentro do seu monólito, sua interface de abstração recém-criada atua como intermediária e destaca a nova implementação. Em pequenos incrementos, você transfere a funcionalidade de notificação para a nova implementação, que permanece inativa até que esteja totalmente testada e pronta. Quando a nova implementação estiver pronta, você muda sua abstração para usá-la. Você gostaria de usar um mecanismo de comutação que possa ser acionado facilmente (como um botão de recurso) para que você possa voltar à funcionalidade antiga facilmente se encontrar algum problema. Quando a nova implementação começar a fornecer todas as funcionalidades de notificação aos seus usuários e o monólito não estiver mais em uso, você poderá limpar a implementação antiga e remover qualquer sinalizador de recurso de troca que possa ter implementado.
![\[Decompor monólitos em microsserviços usando o padrão de ramificação por abstração\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/branch-by-abstraction.png)