J-AXON
Plataforma de gestión de activos de TI y tickets de soporte, reescrita para que un fallo en la interfaz no pueda tumbar el núcleo de datos.
Resultado
6 semanas
de la especificación al sistema funcionando
Cero
cambios de datos sin dejar rastro auditable
3
partes que se actualizan sin apagar el resto
12
documentos de análisis antes de programar
Restricciones
- La IA queda aislada tras un puerto, nunca dentro del núcleo. Si mañana cambia el proveedor, la lógica de negocio no se entera.
- Todo cambio de datos deja registro inmutable. Sin cadena de custodia no hay auditoría que pasar.
- Un fallo en la interfaz no puede comprometer la disponibilidad del núcleo.
El problema
La organización administraba sus activos físicos y tecnológicos con flujos fragmentados. Cuatro cosas se rompían a la vez: un monolito donde el fallo de un módulo de interfaz tumbaba el núcleo de datos, mantenimiento puramente reactivo, registros que se podían alterar directamente en la base de datos, y clasificación de tickets hecha a mano.
El último punto es el que más se siente desde soporte. Un ticket mal clasificado no es una fila mal escrita: es alguien esperando, y un SLA que ya se está desviando mientras nadie mira.
Lo que decidí, y por qué
Arquitectura hexagonal, y la IA fuera del núcleo. Es la decisión que ordena todo lo demás. Meter un proveedor de IA dentro de la lógica de negocio significa heredar su obsolescencia y sus vulnerabilidades. Aislarlo tras un puerto significa que el día que haya que cambiarlo, se cambia el adaptador y el dominio no se entera. La misma regla aplica al framework de interfaz.
Tres servicios, no uno. jaxon-core-api con el dominio y la API, jaxon-client con
la interfaz en Next.js, y PostgreSQL detrás, orquestados con Docker Compose. La frontera
no es estética: es lo que hace que un despliegue de la interfaz no toque el núcleo.
Priorización por riesgo, no por orden de llegada. El triage calcula probabilidad por consecuencia y ordena solo. El objetivo era bajar un 60% el tiempo de asignación inicial.
La especificación antes que el código. Doce documentos: requerimientos de negocio, arquitectura, modelo entidad-relación, contrato de API, matriz de trazabilidad, plan de pruebas y runbook de despliegue. No es burocracia: es lo que permitió que la reescritura de SIGAM a J-AXON supiera exactamente qué tenía que seguir funcionando.
Lo que aprendí
Que la parte difícil no fue el código, sino sostener la frontera. Es muy fácil, con prisa, importar el cliente de base de datos dentro de un caso de uso «solo esta vez». Por eso el proyecto acabó con el gate de calidad puesto: tipos severos, y la regla de dependencia verificada por el linter en vez de escrita en un diagrama que nadie vuelve a abrir.
También que el tamaño no es mérito por sí solo. Lo que hace defendible este proyecto son los 37 archivos de prueba y el hecho de que la especificación existía antes que la primera línea.
Estado
La v2 está en esqueleto: la arquitectura, los contenedores y la especificación están; la implementación del núcleo apenas arranca. Lo que sí funciona completo es la versión anterior, SIGAM, con los mismos 163 archivos de código y 16 de SQL que dieron origen a esta reescritura.