Router de mocks para o core bancário
Um roteador interno que decide, por cenário, se cada chamada vai para o core bancário legado ou para um mock. O time ganha previsibilidade no dia a dia e o legado só é acionado quando precisa ser.
- Meu papel
- Levei a solução para o time
- Onde fica
- Entre as APIs do app e o core bancário
- Ganho
- Menos gasto com o legado e menos espera por ambiente
Contexto
O app mobile bancário em que trabalho se integra a um core legado. Desenvolver e testar o que passa por ele significava chamar o legado.
Problema
Usar o core legado em desenvolvimento e testes custa dinheiro, e depender da disponibilidade dele travava o trabalho do time.
Meu papel
É um dos projetos que levei para o time. Ele parte do mesmo princípio da arquitetura hexagonal: trocar o core real por um mock sem mexer no domínio.
Solução
Uma camada de roteamento entre as APIs e o core, com mocks que reproduzem os cenários de que o time precisa para desenvolver e testar. A cada chamada, o router decide, por cenário, se ela vai para o core legado ou para um mock.
Decisões e trade-offs
Decidir por cenário
A escolha entre core e mock acontece por cenário. Assim o legado só é acionado quando precisa ser, e o resto do trabalho segue com mocks previsíveis.
Roteamento numa camada própria
A decisão fica entre as APIs e o core, não espalhada pelo código. As APIs não precisam saber se estão falando com o legado ou com um mock.
O preço da previsibilidade
Os mocks precisam acompanhar o comportamento do core. Se ficarem para trás, o time testa um cenário que não existe mais. É um custo que vale a pena, mas que precisa de cuidado.
Resultado
Redução de gastos com o legado fora de produção e um ciclo de desenvolvimento mais ágil, sem esperar por ambiente. O time ganha previsibilidade no dia a dia.