Dynamic Form Engine

Origen

Dynamic Form Engine nació a partir de una necesidad observada durante el desarrollo de una plataforma de trámites de movilidad. La plataforma podía representar y renderizar formularios compuestos por secciones, preguntas y distintos tipos de campo, pero no ofrecía un flujo administrativo completo para crear, editar, versionar y publicar esas definiciones.

La intención de DFE era extraer esa capacidad en un motor reutilizable. El proyecto no sustituyó el mecanismo existente ni llegó a integrarse en producción.

Responsabilidad

Creé DFE como proyecto personal y asumí su arquitectura, diseño de base de datos, organización técnica, decisiones de desarrollo y auditorías de código. La experiencia que originó el proyecto ocurrió durante la segunda mitad de mi participación como líder técnico en el sistema de origen.

Para evitar trasladar acoplamientos, definí una frontera explícita: DFE administra formularios, contratos versionados, validación y respuestas; cada sistema huésped conserva autenticación, sesión, roles y contexto de negocio.

Restricciones

• La autenticación, la sesión, los roles y el contexto de negocio debían seguir bajo responsabilidad del sistema huésped.
• Una versión publicada no podía cambiar mientras se preparaba el siguiente borrador.
• El builder no debía depender del router, el store, el layout o el sistema de notificaciones de un host específico.
• Abrir y guardar un formulario no debía eliminar propiedades de contratos JSON todavía no modeladas por la interfaz.

Arquitectura

El backend separa API, aplicación, dominio e infraestructura. PostgreSQL almacena formularios base, versiones, artefactos, respuestas, catálogos, proveedores de datos y auditoría.

Una versión publicada permanece inmutable. Cuando necesita cambios, el sistema crea un nuevo borrador de trabajo. Cada respuesta queda vinculada a la versión concreta que la produjo, evitando interpretar datos históricos con un contrato posterior.

El constructor frontend sigue la misma frontera. Es un módulo Vue 3 que recibe su cliente API, integración con el host y configuración visual. No asume un router, store, layout o sistema de notificaciones global.

Decisiones relevantes

Separar borrador y publicación

Editar directamente un contrato publicado comprometería las respuestas existentes. Por ello, la edición ocurre sobre un borrador y la publicación pasa por validaciones estructurales antes de producir una nueva versión.

Preservar contratos incompletamente modelados

El builder conserva propiedades JSON que todavía no reconoce. Esta decisión permite evolucionar backend y frontend sin perder información al abrir y volver a guardar un formulario.

Validar antes del runtime

Las reglas, validaciones y fuentes de opciones se revisan antes de publicar. El gate detecta referencias inexistentes, configuraciones incompatibles y ciclos de dependencias que serían más costosos de resolver durante una captura.

Mantener responsabilidades del host

DFE no intenta convertirse en un sistema de identidad o de trámites. El host aporta usuarios, permisos y contexto; el motor consume esa información sin incorporarla a su dominio central.

Estado actual

Existe una implementación funcional parcial del backend y del constructor. El motor permite trabajar con formularios, borradores, publicación, reglas, validación runtime y submissions. El constructor permite administrar metadatos, secciones, campos, reglas y varias validaciones.

La actividad verificable de los repositorios comenzó en marzo de 2026 y la última iteración registrada ocurrió en abril de 2026. El desarrollo se pausó cuando terminó mi participación en el proyecto que originó la necesidad, pero planeo continuarlo.

Todavía faltan partes del runtime, enforcement completo durante submit, generación automática del cliente OpenAPI e integración persistente con un sistema huésped.

Evidencia verificada

El 29 de julio de 2026 ejecuté las suites desde las ramas principales inspeccionadas. El backend completó 157 pruebas unitarias y 155 de integración, sin fallos ni omisiones. El builder completó 248 pruebas en 23 archivos y generó su build de producción.

Los conteos describen la implementación auditada en esa fecha. Verifican contratos y comportamiento del código, pero no demuestran integración con un sistema huésped, adopción ni operación en producción.

Resultado

DFE no reemplazó el sistema original y no se presenta como un producto desplegado. El resultado actual es una base técnica reutilizable, documentada y probada parcialmente, que convirtió una limitación observada en decisiones explícitas de arquitectura, versionado e integración.

Siguiente iteración

La continuación debe cerrar primero el recorrido mínimo entre definición, publicación, renderizado y envío. Después puede completar el enforcement de reglas durante el submit, automatizar el cliente OpenAPI e integrar un host de referencia sin mover autenticación ni contexto de negocio al núcleo de DFE.

Aprendizaje

Separar un motor de formularios no consiste solo en extraer componentes. El límite útil aparece cuando el formulario puede evolucionar y conservar su historial, mientras identidad, permisos y proceso permanecen en el sistema que lo consume.