"É Só Mudar Um Número": Por Que Regras de Negócio Espalhadas Custam Caro

Introdução: Uma Mudança Que Não Acaba

“É só mudar o desconto mínimo de dez para cinco por cento.”

Uma semana depois, ainda não foi.

Não é incompetência. É que a regra não mora num lugar só.

Onde a Mesma Regra Costuma Morar

Pegue uma regra simples, como um desconto mínimo para aprovar uma promoção. Ela tende a aparecer em vários lugares:

1. Na validação da tela, para avisar o usuário na hora.
2. No servidor, que confere de novo, porque nunca se deve confiar só no frontend.
3. Numa consulta ao banco, que filtra os pedidos elegíveis.
4. No relatório que calcula a margem.
5. Num campo de configuração que alguém criou dois anos atrás e ninguém lembra por que existe.

Cada cópia foi escrita por uma pessoa, num momento, com um entendimento do momento. Nenhuma delas é a fonte de verdade.

O Problema Não É Só Trabalhoso. É Silencioso

Mudar a regra significa encontrar as cinco, alterar todas e torcer para não existir uma sexta.

A sexta é o pior tipo de erro. O sistema funciona normalmente, não lança exceção, não mostra nada estranho. Só devolve o número errado.

E número errado com aparência normal é o tipo de problema que ninguém investiga até alguém tomar uma decisão com ele.

Como Centralizar Uma Regra

A correção conceitual é simples: a regra precisa de um lugar só, e todos os outros lugares perguntam para esse lugar.

// Fonte única da regra
export const discountPolicy = {
  minimumPercent: 5,
} as const;

// Função pura, testável, sem dependências de tela ou banco
export function isDiscountEligible(percent: number): boolean {
  return percent >= discountPolicy.minimumPercent;
}

Repare no que isso muda:

• A tela chama isDiscountEligible para avisar o usuário.
• O servidor chama a mesma função antes de salvar.
• A consulta pode usar o valor de discountPolicy como parâmetro, e não um número escrito dentro do SQL.
• O relatório importa a mesma constante.

Agora a mudança é em um arquivo. E os testes conseguem provar que todos os lugares obedecem à mesma regra.

Quando a Regra Vira Configuração

Às vezes a regra precisa mudar sem deploy, por exemplo, uma promoção sazonal. Nesse caso, ela pode viver em uma tabela de configuração, mas ainda com uma única fonte:

CREATE TABLE business_rules (
  key TEXT PRIMARY KEY,
  value NUMERIC NOT NULL,
  description TEXT NOT NULL,
  updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
  updated_by TEXT NOT NULL
);

INSERT INTO business_rules (key, value, description, updated_by)
VALUES ('discount.minimum_percent', 5, 'Desconto mínimo para aprovação de promoção', 'renan');

O ponto não é a tabela em si. É que a regra tem nome, descrição, dono e histórico. Quando alguém perguntar por que o número é 5, a resposta existe.

Trade-offs: Centralizar Não É Engessar

Cuidados importantes:

• Config dinâmica exige cache e invalidação. Se o valor muda e o processo continua usando o antigo, você cria outra divergência.
• Regra de negócio não deveria virar uma tabela de parâmetros genérica sem controle. Vira um sistema paralelo difícil de entender.
• Mudança de regra com efeito retroativo precisa de decisão explícita. Pedidos antigos devem ser recalculados ou mantidos com a regra da época?

A regra da época importa. Um pedido aprovado com 10% não deveria mudar de status só porque a política mudou. Para isso, vale registrar a regra vigente no momento da transação.

Checklist: Sua Regra Mora Num Lugar Só?

• Você consegue listar todos os lugares onde essa regra é aplicada?
• Algum desses lugares tem o número escrito à mão?
• Existe um teste que falha se a tela e o servidor divergirem?
• O relatório usa a mesma regra da operação?
• Mudanças de regra registram quem alterou, quando e por quê?

Conclusão: O Sintoma Que Não Precisa de Código

Você não precisa ler código para perceber o problema. Basta olhar para o prazo.

Se uma mudança pequena de negócio leva dias ou semanas, quase sempre a regra está espalhada.

Antes de pedir uma feature nova, pergunte: onde essa regra mora hoje? Se a resposta for “em vários lugares”, o trabalho real é centralizar, e não mudar o número.