Proyecto
IXATU Operations
IXATU Operations es una aplicación moderna orientada a sustituir progresivamente una operativa legacy basada en Microsoft Access y Azure SQL. En lugar de exigir una migración completa antes de entregar valor, construye capacidades concretas sobre datos reales y utiliza el feedback del negocio para hacer explícito el conocimiento acumulado en el sistema histórico.
Estado actual, en una frase:
read-only foundation remains
+
first controlled writer exists in DEV
+
PROD writing remains disabled
+
future migration/replacement remains progressiveEl detalle del cambio de fase está en Del read-only al primer writer controlado.
El problema
El punto de partida combina una interfaz en Microsoft Access, persistencia histórica en Azure SQL, reglas de negocio acumuladas, conocimiento implícito y deuda técnica. La dificultad no consiste únicamente en cambiar unas herramientas por otras: una sustitución acelerada podría perder excepciones y decisiones operativas que nunca llegaron a documentarse.
El proyecto evita una migración big bang. Cada capacidad nueva debe conservar lo que el negocio necesita, distinguir anomalías de reglas reales y aportar evidencia antes de retirar la parte equivalente de Access.
El enfoque
La primera progresión conecta el producto moderno con el origen existente mediante una frontera explícita:
Legacy real
↓
Adapter / Anti-Corruption Layer
↓
dominio moderno
↓
FastAPI
↓
UI
↓
feedback del negocioEl trabajo avanza mediante vertical slices que atraviesan datos, dominio, API e interfaz y terminan en una validación humana. Así, una utilidad operativa —por ejemplo, un panel que señala registros que requieren atención— sirve a la vez como producto y como instrumento para descubrir el dominio real.
Principio central:
Primero sustituir el comportamiento de Access; después sustituir su modelo de datos.
PostgreSQL forma parte del destino progresivo de la arquitectura. El primer writer controlado demostrado escribe todavía en Azure SQL DEV sobre el modelo legacy. No debe leerse como si Operations ya escribiera el dominio canónico moderno en PostgreSQL.
Arquitectura y seguridad
La Anti-Corruption Layer concentra la traducción de nombres, representaciones y excepciones heredadas para que el dominio moderno no dependa directamente del modelo legacy. La arquitectura hexagonal mantiene esa frontera separada de FastAPI, la interfaz React y la persistencia, mientras Liquibase gobierna la evolución del esquema moderno.
La base de lectura se mantiene con permisos mínimos. El carril de escritura en DEV añade identidad Entra, autorización por allowlist, separación reader/writer, ETag/rowversion, transacción y auditoría sin PII. Los entornos DEV y PROD permanecen separados: PROD no tiene writer configurado en esta fase (PROD_MUTATIONS = 0).
Docker Bake, locks y promoción de artefactos forman parte del delivery reproducible del proyecto; ver Docker Bake, uv.lock y reproducibilidad.
Estado y objetivos
IXATU Operations está en desarrollo activo. La fundación read-only sigue siendo el suelo del producto. Encima existe ya un primer writer vertical en DEV, deliberadamente pequeño en negocio y completo en arquitectura.
Los siguientes frentes incluyen estabilizar ese carril, ampliar formularios de Contacto con discovery previo, abstraer solo lo demostrado, habilitar CLI/agentes sobre la misma API —nunca SQL directo— y, más adelante, un gate explícito para el primer writer en PROD.
El resultado buscado no es una réplica tecnológica del sistema anterior, sino un producto operable cuyo diseño se apoye en conocimiento contrastado y que permita completar la modernización sin un corte único de alto riesgo.