Idea principal

Una ontología de negocio que se actualiza automáticamente desde el código tiene un defecto simétrico al de la documentación que envejece: si cambia sistemáticamente para seguir al código, ya no controla nada. Cuando un agente introduce un error, un segundo agente que actualiza la ontología para hacerlo aceptable convierte la deriva en regla. El modelo pasa a ser una documentación regenerada sin cesar.

El exceso contrario no es mejor: un modelo que prohíbe cualquier evolución contraria a sus reglas actuales impide que el producto cambie.

La vía intermedia consiste en tratar de forma explícita cada evolución del modelo. Cuando la evolución es intencionada y clara, se prepara una modificación versionada de la ontología, que puede aplicarse en una rama de trabajo antes de su validación. Cuando la modificación del código parece contraria a la intención, se corrige el código y no el modelo. Cuando la intención es ambigua, se pide una decisión en lugar de inventarse una regla.

Por qué es importante

El modelo se convierte en un contrato evolutivo entre la intención y la implementación, y no en el reflejo del último estado del código. Es la condición para que sirva de red de seguridad: el código no debe tener razón automáticamente.

Eso obliga a llevar un historial. Un concepto renombrado no debe convertirse en dos conceptos independientes, y una regla eliminada debe seguir vinculada a la decisión que justificó su desaparición, por ejemplo en un pequeño registro de decisiones inspirado en los ADR.

Matices y límites

Cada evolución tratada de forma explícita tiene un coste de atención humana. Si todas las evoluciones pasan por una decisión, el dispositivo frena el desarrollo que debía proteger.

Preguntas abiertas

• ¿A partir de qué volumen de evoluciones pendientes de validar dejan los equipos de leer las propuestas de modificación del modelo y las aprueban por defecto?