Como um Padrão de Projeto reduziu a complexidade e manutenabilidade de um grande player do mercado

Se você já leu alguns dos meus outros textos, já pode ter notado que eu gosto bastante de Design Patterns e de como eles me ajudaram/ajudam na minha carreira.

Dessa vez, queria compartilhar uma experiência que tive usando o Factory Method e como ele diminuiu drasticamente a manutenibilidade e ajudou a evoluir um dos projetos em que trabalhei.

Senta que lá vem história…

Vamos para o começo de 2024. Eu havia acabado de entrar no time responsável por enviar todos os pedidos pagos para o WMS (Warehouse Management System).

O desafio? Fazer isso de maneira genérica para atender dois dos maiores e-commerces do país e, se necessário, integrar rapidamente novos sistemas. Na época, a comunicação com um dos WMS era através de uma API, enquanto o outro exigia um insert direto no banco de dados de um sistema controlado por uma empresa terceirizada.

Conversando com o time de negócios, entendemos que, em um contexto geral, o passo a passo seria:

1. Obter as informações do pedido na API de pedidos (meu ex-time).
2. Fazer as validações específicas.
3. Integrar com o WMS (cada um à sua maneira).
4. Receber/confirmar que a integração foi bem-sucedida.
   4.1. Se ocorrer uma falha, precisávamos retentar X vezes.

A resposta dos nossos problemas

Com esse cenário, me lembrei do Factory e fui dar uma olhada no Refactoring Guru para validar se esse padrão me atenderia. Resumo ele me atendeu perfeitamente.

A ideia no geral aqui, é que ao invés de instanciar uma classe com o ‘new’ diretamente, eu tenha um método que saiba me retorna um implementação dentre N possíveis, desde que ela sempre me retorn uma interface/tipo específico.

Vamos dar uma olhada no código:

Aqui temos uma interface padrão que cada integrador do ecom específico precisaria implementar:

Interface que todo integrador deve implementar

As implementações, uma para cada unidade de negócio, ficaram semelhante a isso:

Ambas implementações da nossa interface

Por fim, o meu Factory Method ficou:

O método getWmsIntegrator que irá nos retornar a implementação que desejarmos

Nessa nova estrutura, sempre que surgir um novo ecom, preciso criar um novo integrador com as regras específicas dele (estendendo da nossa interface), adicioná-lo ao meu Factory e adicionar a nova unidade de negócio no enum ‘BusinessUnit’

Pronto! Feito isso, tenho uma nova unidade de negócio pronta para ser implementada, com um código fácil de entender e de manter.

E o dia foi salvo

Esse foi mais um exemplo prático em que vi como um bom conhecimento de negócios e de boas práticas pode ser aplicado com sucesso, entregando resultados para a empresa e para o time de desenvolvimento.

Então, se você é um desenvolvedor, meu conselho é: dedique um tempo para ler blogs e livros sobre padrões de projeto (comece com os clássicos e dê uma olhada no Refactoring Guru). Além disso, aproxime-se do negócio (PM, PO e stakeholders) para dominar seu domínio e entregar resultados reais para o cliente final.

“Um código perfeito que não entrega valor, não serve de nada. Mas um código horrível que gera resultado, gera custo de manutenção”