Ideia principal

Uma ontologia de negócio pode ser complementada por um mapeamento: o conceito de fatura associado às classes, funções, eventos e operações de API que participam da sua implementação. Essas associações não definem o conceito; elas dizem onde ele está implementado.

Essa distinção torna possíveis perguntas que nenhuma das duas camadas responde sozinha. Se você alterar o conceito de fatura, quais partes do código correm o risco de ser afetadas? Se uma função de negócio desaparecer, qual regra pode deixar de estar implementada? Uma nova operação de API expõe um conceito existente ou revela uma noção nova? Uma classe renomeada é um refactoring ou uma mudança real do domínio?

O mapeamento pode ser mantido ao longo das alterações, mas cada associação precisa guardar a sua prova: os arquivos, os símbolos e as mudanças observadas que a sustentam.

Por que isso importa

A análise de impacto deixa de depender da memória de quem conhece o código. E, ao exigir a prova, você separa duas coisas que um LLM confunde com facilidade: uma correspondência comprovada e uma relação apenas deduzida.

Nuances e limites

Uma correspondência deduzida por um LLM é idêntica, na aparência, a uma correspondência comprovada. Sem a prova anexada, o mapeamento acumula ligações plausíveis que ninguém consegue mais distinguir das verdadeiras.

O mapeamento também envelhece: é preciso revisar as correspondências, com uma frequência que ainda não está definida.

Questões em aberto

• Com que frequência é preciso revisar as correspondências entre conceitos e código para que elas continuem confiáveis?