ADR 1 — Política de risco em dado, não em código
O problema
Entre “o cliente pagou” e “o pedido pode ser faturado” existe uma sequência de verificações: confirmação do adquirente, análise antifraude, motor de decisão, às vezes análise humana. Quais etapas se aplicam depende da combinação de empresa, negócio, tipo de operação, canal de origem, país e filial, e ainda do meio de pagamento usado no pedido.
São seis marcas, com e-commerce, aplicativo, mais de duzentas lojas físicas, televendas, atacado e produtos financeiros. O espaço de combinações é grande e cresce, porque cada negócio novo do grupo é uma combinação nova.
O que pesou na decisão
O caminho curto era continuar como estava, com a sequência escrita em condicional por canal. O que me convenceu a não seguir por ali não foi o custo de desenvolvimento, foi o custo de fila: a área comercial abre um negócio e espera a próxima janela de deploy. O número de combinações também não cresce de forma linear, e a árvore de condições resultante é o tipo de código que ninguém altera sem medo.
Cheguei a considerar adotar um motor de regras de mercado, e descartei por uma razão específica: o meu problema não é lógica condicional complexa, é sequência de etapas. Engine de regras resolve bem o primeiro caso e é peso morto para o segundo, e traz junto uma plataforma inteira para operar, versionar e treinar gente. O custo de operação ficava desproporcional ao problema.
O que sobrou foi a percepção que decidiu tudo: o espaço de variação é fechado e descritível. As etapas de verificação são conhecidas; o que muda por canal é quais delas se aplicam. Isso não precisa de linguagem, precisa de indicadores.
A decisão
A política de cada canal virou dado. Cada canal de origem tem um fluxo por tipo de pagamento, e o fluxo é um conjunto de indicadores que liga ou desliga cada etapa de verificação. Mudar a política antifraude de um negócio inteiro não exige publicar versão.
O desenho é a decisão. O bloco de configuração ligado ao núcleo é o que separa esta arquitetura de uma árvore de condicionais: trocar a política de um canal é escrever naquele cilindro, não publicar versão.
O que eu aceitei junto
A configuração virou estado crítico do sistema. Um indicador errado muda a política de risco de um negócio inteiro, sem erro e sem alerta. O risco saiu do código e foi para os dados, onde as ferramentas de proteção são piores: não há revisão de código, não há teste automatizado, não há histórico legível de quem mudou o quê.
O comportamento deixou de ser legível no código. Ler o repositório não responde mais “o que acontece com um pedido deste canal”. É preciso consultar o dado, e para quem chega novo no sistema isso é uma barreira real.
Aceitei os dois porque erro de configuração é reversível em minutos, enquanto deploy errado não é.
Como envelheceu
Bem no essencial, mal no acessório. Canais novos foram abertos sem deploy, que era o objetivo, e isso se manteve por três anos.
O que eu não previ foi o crescimento da superfície de configuração. Hoje não existe um lugar único que responda “o que esta combinação faz”, e a resposta é reconstruída lendo dado espalhado. O custo apareceu no suporte, não no desenvolvimento — que é onde eu não estava olhando.
O que eu faria diferente
Duas coisas, desde o primeiro dia:
- Trilha de auditoria e versionamento na configuração. Quem mudou, quando, o que era antes. Trataria a configuração com o mesmo rigor de código, já que ela virou código.
- Um simulador. Dado um pedido hipotético com seus atributos, mostrar por quais etapas ele passaria, sem criar transação real. Resolveria de uma vez o problema de legibilidade que a decisão criou, e teria sido barato construir junto.
Ver também
Pagamentos e antifraude · ADR 4 — Uma implementação por canal, não um motor parametrizado · Como eu trabalho