Flapper
Flapper: descobrir o domínio antes de separar o monólito
O produto não podia parar, e os autores originais já não estavam lá. Antes de migrar, foi preciso descobrir quais fronteiras o banco ainda revelava.
~25% menos tabelas na separação por domínios
O banco legado revela fronteiras; pessoas, autenticação e aeronaves saem gradualmente para contextos com persistência própria.
Contexto
Na Flapper, o produto principal era um monólito PHP com mais de sete anos, pouca documentação útil e sem os desenvolvedores que o haviam criado. A aplicação sustentava a operação de aviação executiva e não podia ser interrompida para uma reescrita.
Restrições
O código e o banco acumulavam regras e dependências difíceis de explicar. Alterações tinham efeitos colaterais pouco previsíveis, e não havia especialistas remanescentes para confirmar como cada parte do sistema deveria evoluir. A migração precisava coexistir com o produto em produção.
Problema
Trocar PHP por outra tecnologia não responderia à dúvida principal: quais regras pertenciam juntas e quais dependências poderiam ser separadas sem quebrar a operação. O sistema precisava de fronteiras de domínio antes de serviços novos.
Decisão
Usei o banco e o código existente como fonte de descoberta. Agrupamentos de tabelas e relações ajudaram a identificar bounded contexts; a partir deles, a migração seguiu o padrão Strangler:
- extrair um domínio por vez, sem interromper o monólito;
- manter em cada contexto apenas a representação local dos dados de que precisava;
- propagar mudanças por eventos em Kafka, em vez de conectar todos os serviços ao banco antigo;
- usar Node.js, NestJS e Go nos primeiros módulos, com gRPC, REST ou GraphQL conforme o consumidor;
- documentar a estratégia e os primeiros módulos para que o time pudesse continuar a transformação.
Alternativa descartada
Reescrever o monólito inteiro, ou manter serviços novos presos ao mesmo banco e às mesmas relações compartilhadas. A primeira opção pararia o negócio; a segunda preservaria o acoplamento que a migração precisava reduzir.
Resultado
A separação por domínios reduziu em aproximadamente 25% o número de tabelas e criou sete bancos organizados por contexto. Os módulos de pessoas, autenticação e aeronaves foram os primeiros passos de uma transformação planejada para continuar além da entrega inicial.
Limitações
O número mede a redução de tabelas nessa separação de domínios, não um ganho financeiro, a migração completa ou um resultado de mercado da empresa. A data final da experiência tem divergência histórica em fontes antigas; o período publicado segue o perfil exportado. Se um domínio ainda depender de regras não mapeadas no monólito, sua extração precisa ser adiada ou receber uma integração de transição explícita.