A regra que muda toda semana não deveria estar no código

Por que a regra que muda toda semana não pertence ao código#

Regra de negócio é dado, não código. Todo pedido de mudança que exige um deploy para trocar um número, um prazo, um limite ou um critério de aprovação é sintoma de uma decisão de arquitetura tomada errado antes, quando alguém escreveu como constante aquilo que o negócio trata como cadastro.

A pergunta aparece em toda descoberta, e sempre com as mesmas palavras: "e quando a regra mudar, eu dependo de vocês?". A resposta honesta não é sim nem não. É: depende de onde a regra foi colocada, e isso se decide antes da primeira linha.

O caso que deixa isso mais nítido é a genômica. Quando construímos o SheepGen para a DNA Genética do Brasil, a plataforma de avaliação genômica de ovinos, o cliente descreveu o próprio trabalho assim: "pesquisas novas, a gente cria um campo novo, recalcula e entrega de novo". Não era um pedido de recurso futuro. Era a premissa do negócio dele. A cada publicação científica, um marcador genético ganha direção e passa a pontuar. Qualquer sistema com essa regra escrita em código nasceria desatualizado, e envelheceria mais rápido do que a equipe conseguiria fazer deploy.

O que vira parâmetro e o que continua código#

O critério não é gosto de engenheiro nem preferência do cliente. São três perguntas sobre a regra, e as respostas empurram para lados opostos.

Três "sim" e a regra pertence ao cadastro. Três "não" e ela pertence ao código, e insistir em parametrizar só transfere a complexidade para um lugar onde não existe teste.

A linha costuma passar dentro da mesma fórmula, e é aí que a decisão fica concreta:

Repare no último. Numa plataforma multi-tenant que escopamos, o fuso horário ficou fixo e a personalização visual ficou em cerca de doze temas fechados, em vez de campo de cor livre. Foi decisão consciente: cada opção aberta vira um estado a mais para testar, e um estado a mais para alguém configurar errado.

Como a regra virou dado num domínio que muda todo mês#

No SheepGen, a decisão estruturante foi tratar a interpretação genética como catálogo, não como algoritmo. A equipe da DNA Genética cadastra o marcador e, para cada combinação de genótipo e raça, define o composto, a pontuação e a classificação. Quem mantém o cérebro do sistema é o geneticista, não o programador.

O tamanho disso é o que surpreende: nenhum marcador vale sozinho, porque é a relação entre eles, dentro do composto e da raça, que produz a nota. Por isso o catálogo tem 76 marcadores e 1.103 regras, e não 76 respostas. O mesmo SNP pontua diferente em raças diferentes, e marcador tem ciclo de vida próprio (ativo, aguardando direção, bloqueado), porque é assim que a ciência funciona.

A segunda decisão foi separar o dado bruto do cálculo. O arquivo do laboratório, 4,3 GB e 59 milhões de linhas, sobe direto para o armazenamento e é lido em streaming; cada leitura útil é gravada como dado do animal, independente de qualquer pontuação. A consequência é o que o cliente pediu sem usar o nome técnico: o recálculo virou um botão. E quando um marcador é cadastrado depois da importação, o sistema relê o arquivo que já está guardado e grava só o que faltava, sem pedir nada novo ao laboratório.

Isso foi provado ao vivo, no ambiente real: cadastramos um marcador novo, o sistema releu os 4,3 GB, gravou as 734 leituras que faltavam e recalculou os 735 laudos em 4 minutos. Depois da prova, o marcador de teste saiu e o recálculo devolveu o número validado. A conta fecha nos dois sentidos.

O mesmo padrão sustenta o sistema de genética bovina que construímos para a DNA Genética, na plataforma DGA Intelligence: cada campo declara a própria natureza (genotípico, fenotípico ou morfométrico), e daí decorre se ele pontua e se converte para outro campo. Na conversão do sistema legado para o novo, foram 32 campos com regra de normalização e fatorização por raça e sexo, mais 12 modelos genéticos, todos carregados como dado. A granularidade em si é decisão de código: conversão é por raça, normalização é por raça e sexo. Os valores dentro dela são cadastro.

Quando a regra vive na cabeça das pessoas#

O caso mais didático de parametrização não vem de um domínio científico. Vem do crédito.

Na Ideal Veículos, rede de 11 lojas, o F&I é o trabalho de encontrar, entre dezenas de financeiras, quem aprova aquele cliente naquele veículo e em que condições. É um processo que sustenta parte relevante da receita da revenda, e a regra dele não estava em lugar nenhum: vivia na cabeça de quem tinha experiência. Conhecimento tácito, mal documentado, que se perdia na rotatividade natural de um time comercial.

A virada foi cadastrar essa regra. Cada uma das 19 financeiras passou a ter os próprios critérios registrados na plataforma (que veículo financia, ano mínimo, se aceita leilão, se exige CNH), e o sistema passou a recomendar as financeiras certas para cada cliente e veículo, com ranking por financeira. O que era memória de um profissional sênior virou sugestão do sistema.

O efeito de volume vem depois, e é o que prova que aguentou operação real: em 13 meses no ar, 11.364 financiamentos e 51.595 propostas registradas, com 10.494 clientes no histórico. Antes, só a proposta final entrava na planilha; agora cada tentativa fica registrada. Esse é o ponto que uma tela de configuração compra e que um algoritmo escondido não compra: a regra sobrevive à saída da pessoa que a conhecia.

Onde a IA não entra#

Parametrizar regra e gerar texto com IA parecem vizinhos, e são coisas opostas. A fronteira fica visível no Sistema Cuidar, a plataforma de diagnóstico de risco psicossocial que construímos para atender a NR-1.

O laudo tem 15 seções. As institucionais (capa, apresentação, introdução, objetivo, metodologia, caracterização da amostra, dimensões avaliadas) vêm de template versionado. A matriz de risco dos 13 fatores é renderizada direto do dado extraído, sem IA nenhuma: é aritmética e regra, auditável linha por linha. Só então a IA entra, para escrever 5 seções que exigem interpretação técnica, em cinco chamadas independentes e paralelas, cada uma regenerável sozinha. O texto cai num editor onde a responsável técnica revisa antes de exportar.

A regra que define o produto é essa: a IA escreve e não calcula. É o que torna o documento assinável, porque nenhum número do laudo veio de um modelo de linguagem. O mesmo princípio vale quando a IA entra como interface: na camada de IA que modelamos para a DGA Intelligence, um servidor MCP que expõe o sistema como ferramentas conversáveis, o escopo diz que a IA não calcula genética, ela aciona o motor determinístico que já existe pela mesma API da tela, herdando limites, permissões e auditoria. Vale registrar que essa camada está modelada e orçada, não entregue.

O preço de parametrizar demais#

Esta é a parte que quase ninguém escreve, e é a que separa parametrização de uma armadilha caríssima.

Um sistema que parametriza tudo vira uma linguagem de programação ruim dentro de um formulário de administração. Ela tem condicionais, tem precedência entre regras, tem efeito combinado, e não tem nada do que uma linguagem de verdade tem: sintaxe verificável, teste automatizado, revisão de código, histórico legível de mudança. Martin Fowler já registrava em 2009, escrevendo sobre motores de regra, que o problema não é a regra isolada, que sempre parece sensata: é que uma mudança pequena num lugar produz consequências não intencionais em muitos outros, porque o fluxo do programa fica implícito.

O sintoma prático é sempre o mesmo. Erro de configuração não produz erro visível. Produz número plausível.

Vivemos isso na conversão do catálogo genético. Um marcador tinha a nomenclatura de alelo decidida linha a linha, e nessa forma um genótipo casava por uma convenção e o outro casava por outra: meio marcador certo, sem nenhuma mensagem de erro. O sistema teria emitido laudo com nota errada e cara de certa. A correção foi tirar a decisão do dado e passá-la para uma regra por marcador, e o marcador problemático entrou bloqueado até alguém decidir a convenção dele. Duas lições: parte da configuração pertence ao código, e configuração que não dá para conferir não deve existir.

E há o custo silencioso do volume. As 1.103 regras do catálogo existem numa planilha conferível linha a linha, com procedência de cada uma. Mesmo assim, por semanas, a conferência humana completa dessas 1.103 linhas era uma pendência aberta, e não uma tarefa feita. Cadastro grande transfere trabalho, não elimina trabalho. Quem promete "é só configurar" está descrevendo a parte fácil.

Então a régua para abrir um campo de configuração é econômica: cada campo tem que se pagar em mudanças reais que a equipe do cliente fez sozinha. Campo que ninguém mexeu em um ano custou tela, teste, documentação e risco, e não devolveu nada.

Como se verifica que a regra parametrizada está certa#

Parametrizar sem forma de conferir é pior que deixar a regra no código, porque a regra errada não avisa. Num documento que orienta decisão de reprodução de rebanho, de crédito ou de saúde ocupacional, número errado com cara de certo é o pior defeito possível.

A técnica que resiste é comparar o sistema com um caminho de cálculo independente, sobre os mesmos dados. No SheepGen o motor de pontuação não foi apenas testado: foi conferido contra um conferidor escrito separado de propósito, rodando fora do sistema. Os dois tinham que chegar ao mesmo laudo, animal por animal, composto por composto. Resultado na primeira carga real: zero divergência em 55.050 leituras de 735 animais. E a igualdade passou a ser guardada por teste automatizado, então qualquer mudança no motor que descole do conferidor quebra a suíte antes de chegar em produção.

Conferir contra a origem pega também o que veio errado de fora: quando 71 animais saíram com um composto zerado, a revalidação contra os arquivos originais achou uma classificação trocada na planilha de origem, marcadores registrados no composto errado. Corrigida com o cliente, a soma de cada animal não mudou um ponto, porque era reclassificação, e o composto zerado caiu de 71 animais para 2, os 2 corretos.

O mesmo método vale quando existe um sistema antigo para comparar. Na substituição do legado da DNA Genética, montamos um pacote de homologação com dado real convertido (54 touros, 200 fêmeas, 32 campos e 12 modelos genéticos) para rodar os dois motores sobre os mesmos insumos. O sistema que está sendo desligado é o melhor oráculo disponível, é grátis, e existe uma vez só.

Três formas de conferência, em ordem de custo:

Quem mexe no parâmetro depois, e o que fica registrado#

Uma regra que virou dado passou a ser editável por alguém que não é programador. Isso é o objetivo, e é também um vetor de incidente novo: quem pode mudar, o que a mudança afeta e como se descobre depois o que foi mudado.

O mínimo que um sistema parametrizado precisa carregar:

• Versão do conjunto de regras em cada resultado. No SheepGen, cada análise grava a revisão do catálogo e a data do cálculo, e o laudo em PDF estampa as duas: um contador sobe a cada escrita em marcador ou regra. Dois laudos do mesmo animal, de épocas diferentes, nunca se confundem, e a pergunta "sob qual regra este número saiu?" tem resposta.
• Permissão por papel, no parâmetro e não só na tela. Quem opera consulta; quem responde pela regra edita.
• Confirmação explícita para ação que grava. No escopo da camada de IA da DGA Intelligence, toda ferramenta que grava ou dispara lote exige confirmação do usuário.
• Recálculo explícito, nunca silencioso. Mudar a regra e recalcular são dois atos. Recálculo automático em cima de documento já emitido é como se perde a rastreabilidade.

Vale a honestidade sobre o degrau que falta: registrar a revisão do conjunto de regras responde "qual regra produziu este número", que é a pergunta que importa para conferir a conta. Registrar quem mudou a regra e o que exatamente mudou é uma camada a mais, de trilha por usuário, e ela não é automática. Sistema que abre configuração para o cliente e não constrói essa trilha está trocando dependência de deploy por ausência de rastro.

Perguntas frequentes#

Quando a regra do meu negócio mudar, eu vou depender de vocês?#

Depende de onde a regra foi colocada, e isso é decidido no projeto, não depois. Regra que muda por publicação científica, norma nova ou negociação comercial precisa nascer como cadastro que a sua equipe mantém. No SheepGen, o catálogo de interpretação genética tem 1.103 regras cadastradas pela equipe do cliente, e um marcador novo recalcula os 735 laudos do rebanho em 4 minutos. Já a regra que muda uma vez por ano, ou que ninguém fora do time técnico sabe responder, fica no código de propósito: virar tela de configuração custaria mais do que economiza.

Qual é o critério para decidir se algo vira parâmetro ou fica no código?#

Três perguntas resolvem quase todos os casos. Quem sabe a resposta certa: se é quem opera, e não quem programa, a regra tende ao banco. Com que frequência muda sem aviso: se muda por evento externo, o banco ganha. E a regra cabe num formulário fechado: se a forma dela é estável e só os valores variam, é parâmetro; se cada caso tem uma forma diferente, é código. Quando a resposta às três é sim, parametrizar economiza deploy; quando é não, parametrizar só transfere a complexidade para um lugar sem teste.

Parametrizar demais é um problema real?#

É o erro mais caro dessa família, e quase ninguém escreve sobre ele. Um sistema com tudo configurável vira uma linguagem de programação ruim dentro de um formulário de administração: ninguém entende o efeito combinado das opções, nada disso é coberto por teste, e um erro de configuração produz número plausível em vez de erro visível. Martin Fowler já alertava em 2009 que a facilidade de mudar uma regra isolada é justamente o que torna as consequências imprevisíveis. Na prática, cada campo configurável tem que se pagar em mudanças reais que a equipe do cliente fez sozinha.

Como eu sei que a regra que cadastrei está certa?#

Só há uma forma que resiste: comparar o resultado do sistema com um caminho de cálculo independente, sobre os mesmos dados. No SheepGen escrevemos o motor de produção e um conferidor separado, fora do sistema, e os dois tiveram que chegar ao mesmo laudo animal por animal. Na primeira carga real deram zero divergência em 55.050 leituras, e a igualdade passou a ser guardada por teste automatizado: qualquer mudança no motor que descole do conferidor quebra a suíte. Parametrizar sem essa conferência é pior que deixar a regra no código, porque a regra errada não avisa.

A IA pode cuidar da regra de negócio no lugar do parâmetro?#

Não para calcular. No Sistema Cuidar a IA escreve 5 das 15 seções do laudo, e a matriz de risco dos 13 fatores é calculada do dado, sem IA nenhuma: é aritmética e regra, auditável linha por linha. É essa separação que torna o documento assinável por uma responsável técnica, porque nenhum número do laudo veio de um modelo de linguagem. A IA é uma boa camada de conversa por cima de um motor determinístico, e uma péssima substituta dele.

Fontes#

• Martin Fowler, Rules Engine (2009): https://martinfowler.com/bliki/RulesEngine.html

Próximo passo#

Se a sua operação tem uma regra que muda mais rápido do que qualquer fornecedor consegue fazer deploy, o lugar de decidir isso é o projeto, e não a manutenção. Veja como isso ficou no case do SheepGen, onde a equipe do cliente mantém 1.103 regras de interpretação genética sem programador no caminho, e no case da Ideal Veículos, onde a regra de crédito saiu da cabeça das pessoas e virou cadastro. É o tipo de decisão que tratamos em sistemas sob medida, e a fronteira com a IA está no case do Sistema Cuidar e em automação com IA.