Ideia principal

Uma ontologia de negócio atualizada automaticamente a partir do código tem um defeito simétrico ao da documentação que envelhece: se ela muda sempre para acompanhar o código, ela não verifica mais nada. Quando um agente introduz um erro, um segundo agente que atualiza a ontologia para torná-lo aceitável transforma a deriva em regra. O modelo vira uma documentação regenerada o tempo todo.

O excesso oposto não é melhor: um modelo que proíbe qualquer evolução contrária às suas regras atuais impede o produto de mudar.

O caminho entre os dois é tratar de forma explícita cada evolução do modelo. Quando a evolução é intencional e clara, você prepara uma alteração versionada da ontologia, que pode ser aplicada num branch de trabalho antes da validação. Quando a alteração do código parece contrária à intenção, você corrige o código, e não o modelo. Quando a intenção é ambígua, você pede uma decisão em vez de inventar uma regra.

Por que isso importa

O modelo vira um contrato que evolui entre a intenção e a implementação, e não o reflexo do último estado do código. É essa a condição para que ele sirva de rede de segurança: o código não deve ter razão automaticamente.

Isso exige um histórico. Um conceito renomeado não deve virar dois conceitos independentes, e uma regra removida precisa continuar ligada à decisão que justificou o seu fim — por exemplo, num pequeno registro de decisões inspirado nos ADR.

Nuances e limites

Cada evolução tratada de forma explícita custa atenção humana. Se todas as evoluções passam por uma decisão, o dispositivo atrasa o desenvolvimento que ele deveria tornar mais seguro.

Questões em aberto

• A partir de que volume de evoluções a validar as equipes param de ler as propostas de alteração do modelo e passam a aprová-las por padrão?