Ideia principal

Um desenvolvedor que recusa uma ação cria um caso de erro, e dá um nome a ele. CannotEditInvoicedOrder diz "não dá para modificar um pedido faturado": a regra inteira cabe no nome, sem comentário nem documentação. Ninguém escreveu esse nome para documentar coisa alguma — era a forma mais curta de designar a recusa na hora de codificá-la.

Daí um filão inesperado nas partes menos arrumadas do código, aquelas em que nenhuma regra é enunciada às claras: a lista dos nomes dos casos de erro. Ela pode ser lida sem saber programar, já que se trata apenas de ler nomes.

Outros três lugares produzem regras, em rendimento decrescente: as verificações feitas no início da operação, antes que qualquer coisa seja modificada; as restrições do banco de dados — o que precisa ser único, o que não pode ficar vazio; as validações de formulário nas telas.

Por que isso importa

Isso abre a leitura das regras para quem não lê código, e são essas pessoas — suporte, pré-venda, product management — que precisam das regras. A barreira técnica cai justamente na parte do trabalho que parecia a mais técnica.

Isso também dá uma ordem de ataque quando o tempo é curto: começar pelos erros, terminar pelas telas, em vez de percorrer os arquivos.

Nuances e limites

Um nome de erro mal escolhido enuncia uma regra falsa com o mesmo aprumo de um bom: a fonte é densa mas não verificada, e cada regra que sai dela ainda precisa ser confirmada.

E a ausência de caso de erro não diz nada: uma recusa pode ser expressa de outro jeito, ou não existir em lugar nenhum porque a regra não é aplicada. Um objeto descrito sem nenhuma regra sinaliza uma descrição superficial, nunca um negócio sem regras.

Questões em aberto

• O que fazer com as regras que não recusam nada — as que disparam, calculam ou completam —, já que elas não deixam nome nenhum para trás?