Idea principal

Una ontología de negocio puede completarse con un mapa: el concepto de factura asociado a las clases, funciones, eventos y operaciones de API que participan en su implementación. Estas asociaciones no definen el concepto; dicen dónde está implementado.

Esa distinción hace posibles preguntas que ninguna de las dos capas permite por separado. Si se modifica el concepto de factura, ¿qué partes del código corren el riesgo de verse afectadas? Si desaparece una función de negocio, ¿qué regla podría dejar de estar implementada? ¿Una operación de API nueva expone un concepto existente o revela una noción nueva? ¿Una clase renombrada es un refactoring o un cambio real del dominio?

El mapa puede mantenerse a medida que se producen modificaciones, pero cada asociación debe conservar su prueba: los archivos, los símbolos y los cambios observados en los que se basa.

Por qué es importante

El análisis de impacto deja de depender de la memoria de quien conoce el código. Y al exigir la prueba se separan dos cosas que un LLM confunde con facilidad: una correspondencia demostrada y una relación simplemente deducida.

Matices y límites

Una correspondencia deducida por un LLM se parece exactamente a una correspondencia demostrada. Sin la prueba adjunta, el mapa acumula vínculos plausibles que ya nadie puede distinguir de los verdaderos.

El mapa también envejece: hay que revisar las correspondencias, con una frecuencia que nada fija todavía.

Preguntas abiertas

• ¿Con qué frecuencia hay que revisar las correspondencias entre conceptos y código para que sigan siendo fiables?