Ideia principal

O objeto mais central de um software de gestão costuma ter quatro nomes: sales_order no código, "pedido" na tela, um terceiro termo no segundo aplicativo da suíte, "negócio" ou "processo" entre os clientes. O reflexo de engenheiro é enxergar aí uma incoerência a reduzir, impondo uma palavra única em todo lugar.

Isso é errar o problema. Esses três vocabulários — o do código, o da interface, o do campo — não têm a mesma vida útil nem as mesmas restrições, e evoluem separadamente, faça-se o que se fizer. O que se perde quando eles são alinhados à força é a tabela de tradução: a capacidade de reconhecer, na frase de um usuário que fala de "negócio", o objeto do produto de que ele está falando — e de responder a ele com as palavras dele.

Uma ficha de objeto conserva, portanto, as três camadas, mais uma quarta que ninguém pensa em guardar: os termos abandonados pelo caminho. Uma palavra retirada da interface há três anos continua circulando nos tickets, nos materiais de treinamento e nos contratos.

Por que isso importa

É isso que torna um repositório de produto utilizável pelo suporte, pela pré-venda e pelo treinamento, e não só por quem lê o código. Sem a camada "campo", cada pergunta de cliente volta a passar por alguém capaz de fazer a tradução de cabeça.

E essa distância é material de análise: uma palavra usada o tempo todo pelos clientes e ausente do produto sob qualquer nome não sinaliza um problema de vocabulário, e sim uma falta de concepção.

Nuances e limites

Conservar as diferenças não significa mantê-las de propósito: um nome novo introduzido sem razão num terceiro aplicativo continua sendo dívida, e o repositório serve então para torná-la visível.

A camada "campo" envelhece rápido e só tem valor se carregar frequências medidas num corpus real — relatos de entrevistas, tickets — em vez de lembranças de workshop.

Questões em aberto

• Depois de quanto tempo um termo abandonado deixa de ser útil de conservar, e por qual sinal arquivá-lo?