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.

2. Crie uma camada de abstração que represente as interações entre o código a ser modernizado e seus clientes.

3. Quando a abstração estiver pronta, altere os clientes existentes para usar a nova abstração.

4. Crie uma nova implementação da abstração com a funcionalidade reformulada fora do monólito.

5. Mude a abstração para a nova implementação quando estiver pronto.

6. 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, 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

Permite alterações incrementais que são reversíveis caso algo dê errado (compatível com versões anteriores). Permite extrair a funcionalidade que está nas profundezas do monólito quando você não consegue interceptar as chamadas para ele na borda do monólito. Permite que várias implementações coexistam no sistema de software. Fornece uma maneira fácil de implementar um mecanismo de fallback usando uma etapa de verificação intermediária para chamar tanto a funcionalidade nova quanto a antiga. Oferece suporte à entrega contínua, porque seu código está funcionando o tempo todo durante a fase de reestruturação.

Não é adequado se a consistência dos dados estiver envolvida. Requer alterações no sistema existente. Pode adicionar mais sobrecarga ao processo de desenvolvimento, especialmente se a base do código estiver mal estruturada. (Em muitos casos, o lado positivo vale o esforço extra e, quanto maior a reestruturação, mais importante é considerar o uso da ramificação por padrão de abstração.)

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 para chamadas para 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.