
Conexión a una BBDD legacy y modelo read-only
Una aplicación moderna puede leer la fuente de verdad actual sin copiar todo su modelo histórico ni concederse capacidad para modificarlo.
En IXATU Operations, Azure SQL continúa sirviendo al software legacy mientras una nueva aplicación observa capacidades concretas a través de una frontera controlada.
Azure SQL legacy
↓
SELECT explícitos
↓
adapter
↓
Anti-Corruption Layer
↓
Pydantic
↓
FastAPI
↓
Web
El objetivo inicial no es fingir que el origen ya tiene un dominio limpio. Es leer la realidad, protegerla y traducir sólo lo que comprendemos.
El legacy sigue siendo fuente de verdad
Durante la convivencia, la aplicación histórica puede seguir creando y actualizando datos. La aplicación moderna debe asumir que observa un sistema vivo, con reglas y excepciones acumuladas.
Leer directamente las tablas desde cada endpoint propagaría nombres, nulos, códigos y convenciones antiguas por toda la solución. También multiplicaría el coste de corregir una interpretación.
Por eso la conexión física no es el modelo de dominio. Es sólo el primer tramo de una frontera que debe limitar consultas y traducir resultados.
La conexión pertenece al entorno
El mismo código puede conectarse a una base local, de DEV o de PROD mediante configuración diferente. Host, base, driver, identidad y secreto no deben quedar fijados en el repositorio.
Con Python, pyodbc y un driver ODBC pueden proporcionar el canal hacia Azure SQL. Esa elección no obliga a exponer la connection string ni los nombres reales en logs o documentación.
código: contrato de conexión y consulta
entorno: servidor, base, identidad, secreto y opciones
El artículo de configuración por entornos desarrolla esta separación y el motivo para promover el mismo artefacto sin reconstruirlo.
ApplicationIntent no es un permiso
ApplicationIntent=ReadOnly comunica al driver y a la infraestructura que la conexión pretende leer. Puede influir en el routing cuando existe una réplica preparada para ello.
Pero ApplicationIntent=ReadOnly no concede ni revoca permisos. No impide una escritura si el principal SQL conserva autoridad para ejecutarla.
La defensa real está en la base de datos: un principal con mínimo privilegio, autorizado para los objetos y operaciones de lectura necesarios y sin permisos de mutación.
El código read-only y la intención de conexión reducen errores. El permiso SQL limita el impacto incluso si una capa anterior se equivoca.
SELECT explícitos como contrato
Una consulta de integración debería nombrar sus columnas. SELECT * deja que un cambio del origen altere silenciosamente el shape, el orden o el volumen de datos recibidos.
Los SELECT explícitos documentan qué necesita la capacidad. También facilitan revisar permisos, rendimiento y exposición de datos.
SELECT
contract_id,
status_code,
expires_at
FROM legacy_contracts
WHERE expires_at IS NOT NULL;
El ejemplo es deliberadamente genérico. Publicar nombres reales de servidores, tablas privadas o datos operativos no mejora la explicación del patrón.
Leer no significa carecer de impacto. Una consulta sin filtros o índices adecuados puede degradar el origen. El alcance, timeout y plan de ejecución también forman parte de la seguridad operacional.
El adapter contiene el protocolo
El adapter conoce ODBC, parámetros y representación tabular. Ejecuta consultas acotadas y devuelve una estructura que la capa de traducción puede interpretar.
No debería decidir reglas de negocio ni entregar cursores o filas sin tipar a toda la aplicación. Su responsabilidad es aislar el detalle de acceso.
Un adapter pequeño permite probar parámetros, nulos y fallos del driver sin obligar al dominio a conocer pyodbc.
La Anti-Corruption Layer contiene la semántica
La Anti-Corruption Layer traduce nombres heredados, códigos y anomalías hacia un vocabulario moderno. No limpia por intuición ni borra la procedencia de una excepción todavía desconocida.
Pydantic convierte esa traducción en un contrato explícito. Los modelos validan tipos y estados admitidos en la frontera antes de que FastAPI los publique.
fila legacy
↓ adapter
representación de integración
↓ traducción
modelo Pydantic moderno
Si aparece un valor inesperado, la decisión no tiene por qué ser descartarlo. Puede representarse como información insuficiente y convertirse en una señal de discovery.
Attention Board: observar antes de normalizar
Un Attention Board reúne casos que requieren revisión: vencimientos próximos, fechas incoherentes, estados incompatibles o información incompleta.
La interfaz no sustituye el juicio de quien conoce la operación. Hace visible la anomalía y permite preguntar qué regla real explica el dato.
Cada respuesta puede convertirse en una regla, un caso de test o una decisión de migración. Así la aplicación moderna aprende sin reescribir primero toda la persistencia.
Coexistir sin propagar el modelo histórico
El software legacy puede continuar funcionando mientras las nuevas vertical slices leen capacidades concretas. La Anti-Corruption Layer evita que su vocabulario se convierta en el lenguaje permanente del producto.
Cuando un dominio está suficientemente entendido, puede migrarse o adquirir escritura controlada en otro almacén. Hasta entonces, la lectura acotada conserva una frontera clara.
El artículo estratégico de IXATU Operations sitúa este patrón dentro de una modernización reality-first. El artículo sobre modernización de bases legacy amplía la sustitución progresiva sin big bang.
Read-only necesita defense in depth
Una conexión declarada read-only no basta. Deben coincidir consultas sin mutación, superficie de API acotada, principal SQL mínimo, secretos protegidos, red limitada y observabilidad.
El artículo de seguridad por capas explica cómo esas barreras se respaldan. Si el código construye por error una escritura, el permiso SQL debe seguir teniendo la última palabra.
Leer el presente con disciplina permite construir el futuro con evidencia. El legacy deja de ser una caja que hay que copiar y se convierte en una realidad que podemos comprender, encapsular y sustituir progresivamente.