Ideia principal

Quando uma validação só é aplicada pela interface — um teto de desconto verificado no formulário e em nenhum outro lugar —, só duas leituras são possíveis, e as duas são divergências.

Ou é uma regra de negócio de verdade, mal colocada: ela deveria viver onde vivem as regras, e sua presença na tela é um defeito de concepção a arbitrar. Ou ela é contornável — por uma importação de arquivo, pela interface que o produto expõe a desenvolvedores externos — e aí é um defeito com implicação de segurança: o que a tela proíbe, outro caminho autoriza.

O caso inverso se trata do mesmo jeito. Uma regra aplicada pelo núcleo do código que a tela não reflete produz uma recusa incompreensível: o usuário vê sua ação rejeitada sem ver o que fez de errado.

Por que isso importa

Isso transforma a leitura das telas — normalmente relegada ao fim da fila, quando é feita — em uma máquina de encontrar divergências. O rendimento é alto porque a pergunta não exige nenhum julgamento: basta constatar que uma regra não tem gêmea do lado do servidor.

Isso também dá um argumento para não pular essa leitura quando o tempo aperta: é a parte do produto que mais rende por hora gasta.

Nuances e limites

"Quase sempre": uma ajuda de preenchimento sem nenhum alcance de negócio — um formato de data sugerido, um campo escondido para aliviar a tela — não é uma regra e não vira uma divergência.

O contorno supõe outro caminho realmente aberto. Em um produto sem importação nem interface externa, o primeiro caso — a regra de negócio mal colocada — fica sozinho em jogo.

Questões em aberto

• Uma vez a regra levada para o lado do servidor, o que acontece com a validação do formulário: duplicação assumida pelo conforto, ou fonte de divergência futura?