Software Architecture
Explica cómo asignar ownership de datos, escrituras, invariantes y modelos de lectura para evitar bases compartidas sin autoridad y acoplamiento entre contextos.
La arquitectura de persistencia no empieza preguntando qué base de datos usar. Empieza identificando quién posee cada dato, qué invariantes deben protegerse, cómo se consulta la información y qué ocurrirá cuando el modelo evolucione o falle una dependencia.
Los datos no son un recurso neutral compartido por toda la aplicación. Representan decisiones de negocio, estados con significado y reglas que alguien debe proteger.
Cuando varios módulos pueden leer y escribir las mismas tablas sin contrato, el esquema termina funcionando como una API implícita. Cualquier cambio requiere coordinación global y las invariantes quedan repartidas entre servicios, jobs, scripts y reportes.
La arquitectura de persistencia busca responder cuatro preguntas:
Supón que Pedidos, Inventario y Reportes escriben directamente la tabla orders.
Pedidos ───────┐
Inventario ────┼→ orders
Reportes ──────┘Al principio parece conveniente porque todos tienen acceso inmediato. Más adelante aparecen problemas:
El problema no es compartir físicamente una base. El problema es compartir autoridad de escritura y semántica.
Una forma útil de pensar los datos es distinguir autoridad de representación.
fuente de verdad
→ posee reglas e invariantes
→ acepta modificaciones válidas
copias o proyecciones
→ optimizan lectura o integración
→ pueden reconstruirse
→ no redefinen la verdadPor ejemplo:
La duplicación no siempre es incorrecta. Es peligrosa cuando no se sabe cuál copia manda ni cómo reconciliar divergencias.
Ownership significa responsabilidad completa, no solo ubicación de tablas.
El propietario debe definir:
En un monolito modular, varios módulos pueden usar la misma instancia PostgreSQL y seguir teniendo ownership separado mediante schemas, permisos, repositorios y reglas de dependencia.
postgres
├── catalog.* → Catalog
├── inventory.* → Inventory
├── orders.* → Orders
└── billing.* → BillingEl límite lógico existe aunque el despliegue sea único.
Otros módulos no deberían modificar datos ajenos directamente. Existen varias formas de colaboración.
El consumidor solicita una capacidad al propietario.
Orders → Inventory.reserve(items)Es apropiado cuando necesita una respuesta inmediata. Introduce dependencia temporal y disponibilidad compuesta.
El propietario publica un hecho ya ocurrido.
Inventory → StockReservedPermite consumidores independientes, pero introduce retraso, duplicación y necesidad de idempotencia.
El consumidor mantiene una copia optimizada para lectura.
CatalogChanged
→ Search actualiza índice localAumenta autonomía de lectura, pero exige definir staleness y reconstrucción.
En un monolito, una vista de base o función puede exponer datos sin permitir escritura ni conocimiento de internals. Sigue siendo un contrato que debe versionarse.
No es obligatorio usar la misma clase para request, dominio, fila y respuesta.
Expresa reglas e invariantes. Debe hablar el lenguaje del negocio.
Representa cómo se almacena el estado. Puede incluir columnas técnicas, versiones o normalización.
Optimiza una consulta concreta y puede combinar fuentes.
Expone una forma estable para consumidores.
Separarlos aporta valor cuando tienen ciclos de vida o responsabilidades distintas. Duplicarlos por ritual añade mapeos sin reducir riesgo.
El ownership ayuda a ubicar transacciones.
Una transacción debe cubrir las modificaciones que necesitan consistencia inmediata. Si confirmar un pedido exige que estado, líneas y total cambien juntos, pertenecen a una frontera transaccional coherente.
No todo dato relacionado debe estar dentro de la misma transacción. Inventario y Pedidos pueden tener ownership distinto si el negocio acepta un proceso con reserva, confirmación y compensación.
una transacción local
→ garantía fuerte dentro del propietario
varios propietarios
→ coordinación, estados intermedios y convergenciaLa decisión depende de las invariantes, no de una preferencia por microservicios.
Una base compartida puede ser razonable cuando:
Se vuelve problemática cuando:
Una base por servicio aumenta aislamiento operativo y libertad de evolución, pero no crea autonomía automáticamente.
Introduce:
No debe adoptarse como regla estética. Solo tiene sentido si existe autonomía de equipo, despliegue y dominio que justifique el costo.
Supón este flujo:
confirmed si la reserva existe.Una opción dentro de un monolito modular es usar una transacción coordinada localmente si ambos módulos viven en el mismo proceso y la invariante lo requiere.
Otra opción es separar propietarios:
Orders: pending_stock
→ solicita reserva
Inventory: reserved / rejected
→ responde o publica resultado
Orders: confirmed / rejectedEsta segunda opción admite autonomía, pero añade estados intermedios, timeout, idempotencia y reconciliación. No es “más moderna”; compra una capacidad concreta a cambio de complejidad.
Una migración segura considera coexistencia entre versiones.
Evita cambiar schema y código de forma destructiva en un único despliegue.
Deben ser:
Revertir código no siempre revierte datos. Antes de migrar define qué ocurrirá con escrituras realizadas en el nuevo formato.
Una proyección derivada debe responder:
Por ejemplo, un índice de búsqueda puede reconstruirse desde Catálogo. No debería convertirse en autoridad para precio o disponibilidad.
Las consultas analíticas suelen necesitar datos de varios dominios. Permitir que herramientas de BI golpeen directamente tablas operacionales crea acoplamiento y riesgo de rendimiento.
Alternativas:
El pipeline debe conservar lineage, clasificación y reglas de retención.
Ownership también incluye:
Eliminar una fila principal no garantiza eliminación de cachés, índices, archivos, logs o backups. La arquitectura debe conocer todas las representaciones.
Usa transactional outbox o mecanismo equivalente para evitar perder el evento.
Define staleness y asegúrate de que el contrato siga siendo compatible durante el lag.
Usa claves naturales, constraints o idempotency keys según la intención. Deduplicar por campos arbitrarios puede fusionar entidades distintas.
Restaurar solo una base puede dejar proyecciones y servicios en tiempos distintos. Se requiere orden, replay o reconciliación.
Una estrategia compartida puede producir hotspots. Considera partición, cuotas o aislamiento dedicado sin romper ownership.
Que un módulo pueda leer una tabla no significa que pueda modificarla. La consecuencia es que reglas críticas quedan repartidas.
Filtra decisiones de almacenamiento hacia dominio y contratos. Se detecta cuando un cambio de columna rompe controladores y consumidores externos.
Los consumidores dependen de internals sin compatibilidad. Corrige exponiendo operaciones, vistas o eventos explícitos.
Aparecen valores diferentes y nadie sabe cuál corregir. Documenta autoridad y agrega reconciliación.
Un cambio destructivo requiere despliegues perfectamente coordinados. Usa expansión y contracción.
Conviene cuando existen equipos autónomos, requisitos de aislamiento, escalas diferentes, ciclos de despliegue propios o riesgo regulatorio.
No conviene multiplicar bases y pipelines cuando un monolito modular con ownership lógico resuelve el problema de manera más simple.
SQL vs NoSQL y elección de base de datos utiliza ownership, invariantes y patrones de acceso para decidir qué capacidades de almacenamiento necesita cada parte del sistema.