El patrón arquitectónico en que se basa Expediente Dinámico diverge totalmente del que inspira los frameworks convencionales. Nosotros llamamos a esta herramienta “spinework” (o espina dorsal de desarrollo). Se centra en incorporar en el propio modelo de datos la totalidad de parámetros necesarios para determinar las directrices de funcionamiento de la aplicación, y administra estas directrices transmitiendo las órdenes al mismo tiempo que los datos necesarios para ejecutarlas.
Así, la aplicación se vertebra y, desde el punto de vista funcional, su ciclo de trabajo pasa a ser el de cualquier sistema dotado de cerebro: la lógica no se aloja en las extremidades funcionales, sino en el mismo núcleo en el que reside la información, y desde ahí las órdenes se transmiten a los recursos del sistema encargados de llevar a cabo las operaciones, que no hacen sino obedecer esas directrices.
Según la perspectiva convencional, el modelo de datos no tiene más función que ser un mero dispositivo de almacenamiento de la información manipulada por la aplicación. Nosotros concebimos la lógica de la aplicación como el resultado natural de la explotación del modelo de datos, de forma análoga a lo que ocurre en el cerebro humano cuando el individuo conduce su vida tomando decisiones de acuerdo con la información que posee: si decide no cruzar la calle porque están pasando coches, la decisión está en el cerebro, no en las piernas.
Pero la clave que nos otorga una ventaja competitiva fundamental es esta: mediante el patrón spinework, no se requiere la creación de una aplicación a medida distinta para producir cada resultado distinto requerido por el cliente, porque no se necesita alterar el código fuente, sino que se informan una serie de parámetros y a continuación se crea o modifica una secuencia de consultas directrices, alojadas de manera organizada en forma de datos, como el resto de elementos de la base de datos.
El caso normal en toda aplicación de gestión es que el cliente demande cambios en las especificaciones del modelo de datos o del control del flujo (lo que suele ser un proceso natural a partir de la propia experiencia con los casos reales). Ante esto, nuestra respuesta es mucho más simple y eficiente, porque por diseño hemos impedido que el problema de alterar las especificaciones se propague por la aplicación. Todo lo organizamos desde el “cerebro”, sin salir del nivel del modelo de datos. Y es así como nuestra espina dorsal permite una evolución del pensamiento no traumática dentro de la propia aplicación, dado que no interfiere con la operatividad del código dedicado a la vista y a la manipulación.
