

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ão strangler fig
<a name="strangler-fig"></a>

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)
