Idea principal

Los dos repartos técnicos de un software no tienen el mismo valor de negocio, y confundirlos cuesta un proyecto entero.

Los módulos —facturación, compras, permisos de acceso— los trazaron desarrolladores, pero se corresponden a grandes rasgos con partes del negocio. Es una descripción parcial, gratuita, validada por años de uso: un punto de partida que sería un error rechazar con el pretexto de que viene del código.

Las tablas, no. Una tabla no es un objeto del negocio: muchas solo sirven para relacionar otras dos tablas, para guardar un rastro técnico, para almacenar tokens de conexión o resultados temporales. Hacer una ficha por tabla equivale a copiar la estructura técnica tal cual y a describir al mismo nivel lo que cuenta y lo que no significa nada para quien habla del producto.

El tercer reparto posible —el de las carpetas, recorridas en orden— no guarda ninguna relación con la importancia de negocio y produce una masa de fichas sin saber cuáles cuentan.

Capa aportada por "Ontology-Driven Design: ¿y si la ontología se convirtiera en la red de seguridad del código generado por IA?" (2026-10-29). La misma distancia vale para las demás unidades del código. Una clase no es necesariamente un concepto de negocio, un paquete nuevo puede no ser más que una reorganización técnica, una función puede implementar una regla sin constituir un concepto. Una ontología que sigue al código debe, por tanto, mantenerse independiente de su arquitectura —hexagonal, Domain-Driven Design o código desordenado—: el modelo representa el dominio, no la estructura técnica.

Por qué es importante

Zanja la primera decisión de un trabajo de descripción: por dónde avanzar. Apoyarse en los módulos cuesta cero y da un orden ya validado; apoyarse en las tablas obliga a rehacer, a mano y objeto por objeto, la criba que la base no hace.

Vale de forma más amplia: un reparto heredado no hay que adoptarlo ni rechazarlo en bloque; se juzga por lo que costó producirlo y por lo que codifica del negocio.

Matices y límites

La aproximación de los módulos sigue siendo una aproximación: objetos expuestos al exterior pueden estar desperdigados por varios módulos y, por tanto, ser invisibles mientras se avanza parte por parte. Por eso el avance modular debe completarse con otros ángulos de enumeración.

Y las tablas conservan un valor, pero como ángulo de control —hacen aparecer objetos almacenados que ninguna descripción menciona—, nunca como plan de trabajo.

Preguntas abiertas

• En un software cuyos módulos ya no se corresponden con el negocio porque la organización ha cambiado, ¿qué reparto heredado toma el relevo?