Se você chegou aqui, provavelmente está lidando com um monólito que parou no tempo ou assistiu à minha palestra sobre Migração de Arquitetura.
Abaixo, deixo o resumo estratégico da apresentação e o link para baixar os slides.
O Princípio Fundamental
Migrações de arquitetura não são projetos estáticos. Ninguém refatora código para ele ficar “bonito”. Nós refatoramos para que a empresa continue competitiva.
Como estrategista e arquiteto, sigo uma regra de ouro: A produtividade é sustentada pela prioridade.
Se o seu time-to-market está sofrendo porque o Backend é um monólito acoplado, essa é a prioridade. E nada nem mesmo o purismo técnico do Frontend deve bloquear a resolução desse problema.
O Resumo da Estratégia
Para migrar sistemas críticos sem parar a operação, utilizamos o padrão Strangler Fig (Figueira Estranguladora). O processo segue a lógica de que o “Sucesso é Sequencial”:
- Estancar o Sangramento: Colocamos um Proxy na frente do legado. Nenhuma requisição nova bate direto no monólito sem passar pelo porteiro.
- Identificar o Alvo: Escolhemos módulos baseados em volatilidade (o que muda muito) e valor de negócio, não apenas em facilidade técnica.
- A Solução “Feia” (Mas Necessária): Se o Frontend é monolítico, usamos Iframes ou Web Components para injetar as novas funcionalidades (já em microsserviços/nova stack) dentro da casca antiga.
- Coexistência Pacífica: O usuário não percebe a mudança. O negócio continua faturando. O time de engenharia ganha tempo para respirar e reconstruir o Frontend antigo em paralelo.
Nota do Arquiteto: Usar Iframe em 2026 parece retrocesso? Sim. Mas assumir uma dívida técnica consciente para desbloquear milhões em valor de negócio não é retrocesso, é senioridade.
📂 Material de Apoio
Nos slides abaixo, você encontrará:
- O passo a passo visual da árvore Strangler Fig.
- Os diagramas de fluxo de requisição com Proxy.
- A matriz de decisão para escolher qual módulo extrair primeiro.
