Mil regras de negócio: no código, num motor de regras ou na planilha do financeiro

Regra que muda toda semana vira dado com dono e vigência. Regra rara fica no código. Motor de regras só com volume e time. Comparação com prazo, custo e risco de saída.

A regra que decide comissão costuma existir em três lugares ao mesmo tempo, com valores diferentes

Se a sua empresa tem umas centenas de regras decidindo preço, comissão, desconto e limite de crédito, o primeiro trabalho é uma medição chata que decide todo o resto: quantas dessas regras mudaram nos últimos doze meses, e quantas vezes cada uma.

O que muda toda semana precisa sair do código e virar dado, numa tabela com dono, histórico de alteração e data de vigência. O que mudou duas vezes em cinco anos continua como um if no meio do serviço, e ninguém vai sofrer por causa disso. Motor de regras dedicado atende um terceiro caso, mais raro do que o folheto do fornecedor sugere: muita regra, mudança frequente, gente de negócio operando sozinha e auditoria pedindo trilha. Existe ainda um quarto lugar, o mais comum de todos, e ele é a planilha do financeiro, que ninguém escolheu e onde boa parte dessas regras já mora hoje.

Uma pergunta de 109 mil visualizações e nenhuma resposta curta

No código a regra tem autor, data e revisor, e uma fila de duas semanas para mudar meio ponto percentual

"How can one manage thousands of IF...THEN...ELSE rules?" está no Software Engineering Stack Exchange com 218 pontos, 109.620 visualizações e 18 respostas. Nenhuma delas é curta, e isso já diz alguma coisa. Se houvesse um jeito óbvio, a pergunta teria morrido no ano em que foi feita.

Quem pergunta isso costuma ser o desenvolvedor que abriu o arquivo de cálculo de preço e achou umas oitocentas ramificações de condição. Quem paga a conta pergunta a mesma coisa com outras palavras: quanto tempo leva para mudar a comissão do canal de parceiros, quem consegue fazer isso sem depender de mais ninguém, e o que acontece com essas regras no dia em que a pessoa que as conhece pedir demissão.

Prazo, autonomia e risco de saída. Esses três critérios separam os três caminhos melhor que qualquer comparativo de tecnologia. Vou por eles.

No código: o melhor histórico da empresa, na pior fila

Regra no código tem a auditoria mais completa que existe dentro da sua empresa, e quase ninguém enxerga isso. Cada alteração tem autor, data, revisor e diff. Dá para rodar um git log no arquivo que calcula comissão e ver quando a faixa mudou, quem aprovou e o que quebrou na semana seguinte. Planilha não faz isso. A maioria dos motores de regras faz pela metade.

O preço aparece na velocidade. Mudar meio ponto percentual numa faixa custa uma tarefa, uma fila de priorização, uma revisão e um deploy. Em time com folga isso são uns dois ou três dias. Em time tocando três frentes ao mesmo tempo, vira duas semanas, e é exatamente aí que alguém do financeiro abre o Excel.

Tem um segundo custo, mais silencioso, e ele é o que aparece nos projetos que chegam aqui depois que o fornecedor anterior virou as costas: as regras estão no código e ninguém sabe explicar por que elas são assim. O if está lá desde 2019, com um número mágico, sem comentário, e o cliente que pediu aquela exceção não trabalha mais na empresa. Código é um registro excelente do que foi feito e um registro ruim do porquê. Isso tem efeito direto em prazo e receita, e entra na mesma planilha de risco onde ficam os outros itens de engenharia.

Eu já estive do outro lado dessa mesa. Na startup de locação de equipamentos que fundei, eu contratava desenvolvedor sem conseguir julgar o que me diziam: pedia uma mudança na regra de preço, ouvia um prazo, anotava e não tinha argumento nenhum para discutir aquele número. A sprint terminava sem a entrega, e eu botava a culpa no time. A pergunta que faltava era mais simples do que eu imaginava na época.

No motor de regras: você tira a regra do deploy e ganha uma operação nova

Quando o sistema calcula 12% e a planilha paga 12,5%, a conversa deixa de ser sobre tecnologia

A promessa do motor de regras é honesta: tirar a regra do ciclo de deploy e deixar o negócio mudar sozinho. Drools, tabela de decisão, DMN, serviço de flags com condição, o mercado tem opção madura e gente séria usando.

A conta que raramente aparece na apresentação é a de operação. A regra escrita no motor continua sendo código, só que num ambiente que quase nunca tem as ferramentas de código em volta: teste automatizado da regra, homologação, revisão por outra pessoa, rollback com um comando. Quando a regra errada entra em produção às três da tarde de uma quarta, você descobre pela conciliação do dia seguinte.

Existe também a parte de desempenho, invisível enquanto o volume é pequeno. Encadeamento que roda rápido na demonstração começa a pesar quando a base cresce e cada pedido dispara centenas de avaliações. Já escrevi sobre esse tipo de surpresa, em inglês, e o roteiro é sempre parecido.

E tem a ironia da concentração de conhecimento. Antes uma pessoa conhecia as regras. Depois do motor, uma pessoa conhece as regras e o motor.

Quando vale mesmo: centenas de regras, mudança pelo menos mensal, uma área de negócio que opera de verdade (crédito, seguro, tributário, preço dinâmico) e exigência formal de trilha de quem mudou o quê. Se três dessas quatro condições não são verdade na sua empresa, você vai pagar a implantação e continuar abrindo chamado para a TI mudar a regra.

Na planilha: cinco minutos para mudar, zero linha de log

A planilha ganha nos dois critérios que importam para quem precisa da mudança: prazo de cinco minutos e nenhuma permissão a pedir. É por isso que ela sempre vence, e é por isso que proibir não funciona. Ela costuma nascer numa sexta de fechamento, quando o número do sistema não bate e alguém precisa pagar comissão na segunda.

O que ela cobra vem depois. Não há histórico de quem mudou a célula, não há teste, e a fonte da verdade se parte em duas. O sistema calcula 12% e a planilha calcula 12,5%. O boleto sai do sistema, a comissão é paga pela planilha, e ninguém percebe por uns quatro ou cinco meses. Quando alguém percebe, a discussão não é técnica, é sobre pagar diferença retroativa para trinta vendedores.

Vale separar duas planilhas que costumam ser tratadas como a mesma coisa. A de simulação, rascunho de cenário antes da decisão, é útil e deve continuar existindo. A que decide dinheiro pago é um sistema em produção sem log, sem dono formal e sem backup, rodando no notebook de uma pessoa que tira férias em janeiro.

"Então é só tirar tudo do código e jogar numa tabela"

Não, e o motivo é chato. Parâmetro cabe em tabela: percentual, faixa, teto, prazo de carência, praça elegível. Isso sai do código com pouco esforço e resolve boa parte do problema real, porque a maioria dos pedidos do negócio é troca de número.

Encadeamento não cabe. Quando a regra é "8% de desconto acima de 50 unidades, exceto para distribuidor, que tem 5%, salvo se o contrato for anterior a 2023", você tenta representar aquilo em colunas e acaba escrevendo um interpretador caseiro dentro do seu próprio sistema. Nesse ponto você construiu um motor de regras sem depurador, sem teste e sem ninguém que o conheça além de quem o escreveu.

O corte que uso é grosseiro e funciona: número vai para tabela com dono e vigência, condição encadeada fica no código com um teste cujo nome descreve o caso de negócio em português. Não sei dizer onde esse corte fica numa empresa com dois desenvolvedores e vinte regras. Nessa escala provavelmente ainda não existe problema para resolver, e mexer nisso é gastar dinheiro adiantado.

Quatro perguntas que colocam cada regra no lugar

Pegue as dez regras que mexem em dinheiro na sua empresa e responda para cada uma:

1. Quantas vezes ela mudou nos últimos doze meses? Zero ou uma vez aponta para o código, uma vez por mês ou mais aponta para dado com vigência.
2. Quem pede a mudança e quem consegue executá-la sem ajuda? Quando as duas respostas são a mesma área, a regra pode viver fora do ciclo de deploy.
3. Quanto custa ela ficar errada por três dias? Comissão errada por três dias é constrangimento, cálculo de juros errado por três dias vira carta de advogado.
4. Se a pessoa que explica essa regra sair numa sexta, quem responde na segunda? Sem um nome nessa linha, o lugar onde a regra mora é o menor dos seus problemas.

A quarta é a mais barata de responder e a que mais dói. Ela também explica por que a hora de quem entende o seu domínio custa o que custa, e a faixa praticada está aqui, com os números de 2026.

A coluna que decide dinheiro e o sistema não conhece

Abra a planilha que o financeiro usa para fechar o mês e procure as colunas que têm fórmula, não valor colado. Cada fórmula dessas é uma regra de negócio que a sua empresa executa todo mês, sem teste, sem histórico e sem dono.

Conte quantas são. Depois pergunte ao time quantas dessas mesmas regras existem também no código, com valor diferente. A distância entre os dois números é o tamanho do trabalho de verdade, e ela costuma ser bem menor que a reescrita que alguém vai propor na próxima reunião.