ADR-0003: El DDL existente como migración base V1
Estado: Aceptado · Fecha: 2026-09-24
Contexto
Antes de escribir una línea de Java ya existía docs/LIS_modelo_datos_postgresql_18.sql:
noventa tablas con restricciones nombradas, restricciones de exclusión para vigencias, seis
vistas y once triggers que codifican reglas del dominio (inmutabilidad de versiones, matriz de
transiciones, coherencia de orden y paciente, bloqueo de lotes vencidos).
El marco de trabajo dice “nada se documenta antes de necesitarlo”, lo que sugeriría trocear el DDL y traer cada tabla en el slice que la necesita.
Decisión
El DDL entra completo como V1__esquema_base.sql. A partir de ahí, toda modificación es una
migración nueva y ninguna aplicada se edita.
Los catálogos de estado y la matriz de transiciones se extraen del archivo de datos de ejemplo
a su propia migración (V2), porque son datos de referencia sin los cuales el esquema no
funciona. Los datos de demostración no son migración: viven en recursos de test y en un perfil
de desarrollo.
Consecuencias
- Conserva un trabajo de modelado coherente y ya revisado.
- Las reglas que el esquema impone están disponibles desde el primer slice.
− El esquema precede al dominio: existen noventa tablas y ningún objeto de dominio. Riesgo de
que un slice modele de más por tener la tabla delante. Se mitiga en el plan: cada slice
modela únicamente lo que su criterio de aceptación exige.
− Una corrección al DDL durante M0 es una migración nueva, no una edición, en cuanto
V1se haya aplicado en cualquier entorno compartido.
Alternativas descartadas
Trocear por slice: desmontar un DDL con dependencias cruzadas, restricciones de exclusión y triggers que abarcan varias tablas cuesta más que el beneficio de no tener tablas sin usar.
Núcleo en V1 y el resto por slice: la frontera entre “núcleo” y “resto” es arbitraria en un esquema donde orden, muestra, resultado e informe se referencian entre sí.