Na Robbin, lidamos com um ecossistema complexo de integrações externas: processadoras de cartão, sistemas bancários, birôs de crédito, registradoras de recebíveis, APIs do Bacen, entre outros. Cada uma dessas integrações traz consigo regras, formatos e comportamentos próprios — e, muitas vezes, imprevisíveis.
Para preservar a saúde do nosso sistema e proteger nosso domínio de negócio contra essas variações, construímos o que chamamos de camada de blindagem.
O que é a camada de blindagem?
A camada de blindagem (ou adapter layer) é responsável por isolar a lógica de negócio dos detalhes de implementação de terceiros. Funciona como uma fronteira clara entre o domínio da Robbin e o mundo externo. Toda integração com um provedor externo passa por ela.
Na prática, ao invés de acoplarmos nosso sistema diretamente à resposta de uma API externa, replicando modelo de dados do provider, criamos representações internas — modelos, contratos, erros — que são estáveis, consistentes e evoluem no ritmo do nosso negócio. A camada de blindagem faz a tradução bidirecional: de fora pra dentro (entrada de dados) e de dentro pra fora (requisições).
Exemplo real: pagamento e leitura de boletos
Na Robbin, usamos um provedor tanto para fazer o pagamento quanto a leitura de boletos — ou seja, todo o ciclo passa por esse mesmo parceiro.
Porém, como fizemos uma modelagem de domínio bem definida, conseguimos representar internamente o conceito de boleto de forma agnóstica ao provedor: com campos e comportamentos que fazem sentido para o nosso negócio, não para a API externa. Além disso, encapsulamos toda a comunicação externa na nossa camada de blindagem, separando claramente o domínio da infraestrutura.
Isso nos dá liberdade estratégica: se surgir outro provedor que ofereça melhores condições econômicas, podemos migrar de forma gradual ou até operar com múltiplos provedores em paralelo — sem que isso cause retrabalho no sistema ou quebre regras de negócio.
Sem essa blindagem, estaríamos presos ao modelo de dados e fluxos do primeiro provedor, o que geraria alto custo de mudança (vendor lock-in) e dificultaria qualquer evolução.
Por que isso é importante?
- Estabilidade do domínio: mudanças em APIs externas não quebram nossa lógica de negócio.
- Facilidade para trocar provedores: se quisermos trocar a fonte de dados, só precisamos ajustar o adapter correspondente.
- Testabilidade: o domínio pode ser testado com dados estáveis e previsíveis, sem depender de mocks complexos de provedores.
- Observabilidade e tratamento de erro centralizado: a blindagem também permite capturar, classificar e tratar erros externos de forma uniforme.
Parentesco com Ports and Adapters
O conceito de layer de blindagem tem uma forte relação com a arquitetura de Ports and Adapters (também conhecida como Hexagonal Architecture), muito usada em domínios ricos e sistemas complexos.
Na analogia:
- Portas (Ports) são as interfaces que o domínio expõe ou consome — por exemplo, CompanyDataFetcher.
- Adaptadores (Adapters) são as implementações concretas dessas interfaces — como SerasaAdapter, ReceitaFederalAdapter, etc.
A camada de blindagem é, na prática, um conjunto de adaptadores que implementam portas bem definidas. Isso garante que o domínio permaneça puro, livre de dependências técnicas ou de formatos externos.
Outros nomes para o mesmo conceito
Dependendo da stack ou da escola de arquitetura, esse padrão aparece com nomes diferentes:
- Anticorruption Layer (ACL): no DDD (Domain-Driven Design), é a camada que protege o domínio contra modelos inconsistentes ou impuros vindos de sistemas externos.
- Integration Layer: nome genérico para a camada responsável por lidar com sistemas de terceiros.
- API Gateway/Facade: em algumas arquiteturas, especialmente quando voltadas a APIs REST, a fachada funciona como blindagem entre cliente e serviços internos.
- Service Adapter: comum em microsserviços e ambientes com muita mensageria.
Quando vale a pena usar?
Em sistemas pequenos ou MVPs, pode parecer “over engineering”. Mas à medida que a empresa cresce, e com ela a quantidade de integrações externas, a blindagem se torna um diferencial: evita acoplamentos perigosos, facilita a manutenção e cria uma base sólida para escalar o sistema.
Na Robbin, essa escolha já nos poupou dezenas de retrabalhos e quebras evitáveis. Para uma fintech que quer ser rápida, mas sem perder a solidez, blindar o domínio é mais que arquitetura — é estratégia.