Ideia principal

Uma exceção chamada ElementAnnuléNonModifiable não é uma mensagem de erro: é uma regra de negócio escrita em código, legível por um agente de suporte que não programa. Uma exceção chamada InvalidStateException diz a mesma coisa ao processador e nada a mais ninguém. É essa distância, e não a qualidade técnica do repositório, que decide se uma pergunta de produto pode encontrar ali a sua resposta.

A condição se estende a todo o material: entidades que carregam os nomes usados pelos usuários, ações cujo título dá para ler, eventos que contam o que aconteceu, políticas que tornam visíveis as reações em cadeia, módulos cuja estrutura é previsível. Um repositório em que os conceitos do domínio ficam escondidos atrás de nomes técnicos e em que as regras estão espalhadas continua opaco, por mais cuidado que se tenha tido com o recorte ou com a cobertura de testes.

A exigência é antiga — as abordagens de design orientadas pelo domínio a sustentam há muito tempo — e não foi criada pela chegada dos assistentes. Um desenvolvedor que assume um repositório assim paga a mesma tradução permanente entre a necessidade de negócio e a mecânica de software; cada evolução exige reconstruir essa ligação, cada busca por uma regra custa mais caro. O que a possibilidade de consultar o código muda é que esse defeito se torna mensurável de fora do time técnico: ele não se traduz mais em lentidão difusa, mas em respostas que ninguém consegue obter.

Por que isso importa

Isso desloca o critério que aplicamos antes de instalar um dispositivo de consulta. A pergunta a fazer a um repositório não é "ele é bem cuidado?", e sim "o vocabulário do domínio está escrito nele?" — duas propriedades que muitas vezes andam juntas e não têm ligação necessária.

Isso também dá um argumento não técnico a um investimento que só tinha um. Renomear conceitos para a linguagem do negócio deixa de ser uma preferência de artesão a partir do momento em que o suporte, a pré-venda e o product management dependem disso para obter respostas.

Nuances e limites

A uniformidade não existe: um mesmo repositório fala a linguagem do negócio no módulo de faturamento, escrito vinte anos antes por gente que conhecia o domínio, e fica mudo na camada de integração. A condição se verifica zona por zona, não no repositório inteiro.

O vocabulário inscrito no código, além disso, tem data. Um nome de entidade que sobreviveu a três reposicionamentos conta um negócio que não se pratica mais, e a própria legibilidade dele o torna enganoso.

Por fim, um nome de negócio correto pode cobrir uma regra errada. Uma exceção expressar uma regra a torna legível, não exata: o que se torna consultável é o código, não o produto desejado.

Questões em aberto

• Quem decide o vocabulário quando os usuários chamam um objeto de um jeito diferente do código, e os dois usos têm quem os defenda na empresa?
• Como medir, antes de começar o trabalho, a distância entre o vocabulário de um repositório e o do domínio?