ADR-0001: Monolito modular por capacidad de negocio
Estado: Aceptado · Fecha: 2026-09-24
Contexto
El LIS cubre dieciséis procesos (P01–P16) sobre noventa tablas, desde la configuración del catálogo hasta la conservación del informe. Los procesos comparten identidad de paciente, orden y muestra, y casi todos escriben en el mismo flujo de trabajo. El equipo es de una persona. No hay tráfico que justifique escalar partes por separado ni límites organizativos que obliguen a desplegar por separado.
Decisión
Un solo despliegue, organizado en módulos por capacidad de negocio (admision, muestras,
analitica, validacion, informes, calidad, finanzas, microbiologia, derivacion,
inventario, seguridad, catalogo, compartido), cada uno con dominio, aplicacion,
infraestructura y api.
Regla de dependencias: api → aplicacion → dominio. El dominio no conoce Spring, jOOQ, HTTP
ni PostgreSQL.
Regla entre módulos: la escritura nunca cruza el límite de un módulo; se invoca el caso de uso del módulo dueño. La lectura sí puede cruzarlo a través de las vistas del esquema.
Ambas reglas son tests de ArchUnit que rompen el build.
Consecuencias
- Los límites existen y se verifican solos, sin coste operativo de red ni de despliegue.
- Si un módulo llegara a necesitar despliegue propio, el límite ya está trazado.
− Nada impide técnicamente un
JOINentre tablas de dos módulos: la disciplina de lectura depende de la revisión, no del compilador. − Un fallo tumba todo el proceso. Aceptable: un laboratorio con el LIS caído para igual.
Alternativas descartadas
Monolito por capas (controllers/, services/, repositories/): con noventa tablas, el
paquete services se convierte en un vertedero y los límites del dominio desaparecen.
Microservicios: exigiría coordinar transacciones entre admisión, muestras y resultados, que hoy son una sola unidad de consistencia. Complejidad operativa desproporcionada para un equipo de una persona y un flujo que no se reparte entre sedes independientes.