Software Architecture
Integra drivers, cualidades, límites, estilos, datos, comunicación, resiliencia, seguridad, equipos y evolución en un modelo completo de arquitectura de software.
La arquitectura de software es un proceso continuo de reducción de riesgo. Conecta objetivos, restricciones, atributos de calidad, límites, datos, comunicación, operación, equipos y evolución mediante decisiones que deben poder explicarse y verificarse.
Después de estudiar patrones, datos, resiliencia y migraciones, el riesgo es tratar cada tema como una herramienta independiente.
El modelo mental integrador es:
contexto y objetivos
→ drivers y restricciones
→ escenarios de calidad
→ dominio e invariantes
→ boundaries y ownership
→ comunicación y datos
→ tácticas y topología
→ decisiones y trade-offs
→ implementación y gobierno
→ evidencia operacional
→ aprendizaje y evoluciónLa arquitectura no comienza preguntando “¿qué patrón usamos?”. Comienza preguntando qué problema existe, qué cualidades importan y qué decisiones serán costosas si están equivocadas.
comprender
→ decidir
→ implementar
→ observar
→ aprender
→ ajustarEl sistema y su contexto cambian:
Por eso la arquitectura no se “termina” antes del desarrollo. Se conserva mediante código, contratos, pruebas, métricas, ownership y migraciones.
Antes de diseñar, identifica:
Ejemplo DomiSys:
problema:
negocios controlan inventario y pedidos mediante herramientas desconectadas
resultado:
operar ventas, pedidos e inventario con información confiable por negocio y sucursalLa arquitectura debe proteger ese resultado, no demostrar sofisticación técnica.
Los drivers son fuerzas que condicionan decisiones.
Capacidades que el sistema ofrece.
Cómo debe comportarse: integridad, seguridad, rendimiento, disponibilidad, modificabilidad, observabilidad y otras cualidades.
Aspectos donde falta evidencia.
Para DomiSys podrían priorizarse:
Alta disponibilidad multirregional podría ser secundaria al inicio.
“Seguro” o “escalable” no orientan decisiones.
Ejemplo:
Durante hora pico,
cuando dos cajeros intentan vender la última unidad,
solo una venta debe reservarla,
ningún stock puede quedar negativo
y las respuestas deben completarse en menos de 500 ms para p95.El escenario conecta:
Ahora es posible discutir transacción, constraint, aislamiento y pruebas.
El dominio define qué reglas deben conservarse.
Preguntas:
Ejemplo:
Inventario posee:
- stock disponible
- reservas
- movimientos
- reglas de recepción y ajuste
Ventas solicita una reserva;
no modifica la tabla de stock directamente.Las invariantes ayudan a elegir boundaries. Si dos partes necesitan una transacción constante, separarlas mediante red puede aumentar riesgo sin beneficio.
Un boundary establece:
Sales
→ posee venta, total, pago asociado y devolución
Inventory
→ posee stock, reservas y movimientos
Orders
→ posee ciclo del pedido y fulfillmentOwnership significa autoridad de escritura y evolución. Otros módulos pueden consultar mediante contratos o proyecciones, pero no compartir reglas implícitas.
Las reglas importantes no deberían depender directamente de detalles volátiles.
transportes y adapters
→ casos de uso
→ dominioEl dominio puede declarar puertos para mecanismos relevantes:
No toda clase necesita interfaz. La abstracción protege fronteras reales, no satisface una plantilla.
Preguntas maestras:
Ejemplo:
venta confirmada + movimiento de inventario
→ transacción local cuando comparten boundary operativo
búsqueda de catálogo
→ proyección derivada con consistencia eventualNo todo requiere la misma consistencia. Dinero e inventario suelen necesitar coordinación fuerte; analítica y búsqueda pueden tolerar retraso explícito.
Adecuada cuando el consumidor necesita una respuesta para continuar.
Costos:
Adecuada para propagar hechos, desacoplar tiempo o procesar trabajo diferido.
Costos:
Pregunta:
¿El consumidor necesita conocer el resultado ahora,
o necesita enterarse de un hecho para actuar después?No uses eventos solo para “desacoplar”. Debe estar claro quién posee el hecho y qué garantías existen.
Opciones como monolito modular, microservicios o serverless son medios.
Útil cuando:
Útiles cuando:
La red no crea boundaries. Un límite débil dentro del monolito se vuelve más difícil al distribuirse.
Una táctica responde a un atributo concreto.
Ejemplos:
La táctica debe justificarse mediante escenario y trade-off. Caching mejora latencia, pero introduce staleness. Retries recuperan fallos transitorios, pero aumentan carga.
Un ADR útil contiene:
Decisión:
Mantener Inventario y Ventas en monolito modular.
Razón:
Equipo único, transacciones críticas y ausencia de necesidad de despliegue independiente.
Costo:
Escalado y despliegue conjunto.
Revisar cuando:
Existe equipo separado o volumen independiente sostenido.La decisión puede cambiar sin que la original haya sido incorrecta.
La arquitectura documentada debe reflejarse en:
regla: Sales no escribe Inventory
implementación:
- repository de Inventory es interno
- permisos de DB limitan escritura
- Sales usa InventoryPort
- test de arquitectura bloquea imports
- auditoría registra ajustesSin mecanismos, la intención se erosiona.
Pregunta antes de producción:
Una arquitectura que requiere capacidades que el equipo no posee no está completa.
No existe una prueba única que demuestre “buena arquitectura”. Se acumula evidencia sobre riesgos concretos.
Cuando una decisión deja de servir:
Evita reescrituras sin estrategia de coexistencia.
Una arquitectura inicial coherente podría ser:
Clientes web y móviles
↓
API / transport adapters
↓
Monolito modular
├── Identity & Tenancy
├── Catalog & Inventory
├── Sales & POS
├── Orders & Delivery
├── Purchasing
├── Payments adapters
└── Reporting projections
↓
PostgreSQL con ownership por módulo
↓
Outbox para efectos asíncronos selectivosConserva una estructura suficiente hoy y señales para evolucionar.
Toda solución depende de contexto.
El futuro es incierto. Preserva opciones y usa evidencia.
Las decisiones tienen trade-offs.
Procesos distintos pueden seguir completamente acoplados.
El código, los datos y la operación definen la arquitectura ejecutada.
Una arquitectura madura elimina complejidad accidental y acepta solo la que compra valor.
1. Describe el problema.
2. Escribe el escenario.
3. Identifica invariantes y ownership.
4. Compara al menos dos alternativas.
5. Elige la opción más simple suficiente.
6. Registra trade-offs.
7. Define cómo comprobarla.
8. Define cuándo revisarla.Una respuesta sólida no nombra únicamente tecnologías. Conecta cada decisión con un driver, explica ownership y garantías, reconoce trade-offs y define una forma de verificación o revisión.
Esta nota no reemplaza las anteriores. Funciona como mapa para regresar al tema específico cuando una decisión lo requiera: