Software Architecture
Compara estilos arquitectónicos y explica cómo elegirlos según drivers, límites, consistencia, despliegue, operación, equipo y coste de evolución.
Un estilo arquitectónico define una familia de estructuras, restricciones y formas de colaboración. Elegir uno no consiste en seleccionar el patrón más prestigioso, sino en comprobar qué drivers satisface y qué costos introduce.
Los estilos ayudan a razonar sobre la forma global de un sistema:
Un sistema real puede combinar estilos en escalas distintas.
sistema: monolito modular
módulo: arquitectura hexagonal
procesamiento: pipe and filter
eventos: integración asíncrona selectivaSin un vocabulario estructural, el equipo toma decisiones aisladas que pueden contradecirse. Un estilo ofrece restricciones conocidas y trade-offs estudiados.
El error aparece cuando se adopta como receta universal. “Microservicios”, “event-driven” o “Clean” no son niveles de madurez.
Organiza por niveles de abstracción.
presentation → application → domain → infrastructureFunciona mejor combinada con módulos o vertical slices.
Protegen un núcleo mediante inversión de dependencias.
Una unidad de despliegue con módulos fuertes por capacidad.
Requiere reglas de dependencia y ownership, no solo carpetas.
Servicios desplegables de forma independiente, alineados con capacidades y datos propios.
No aportan autonomía si cada cambio exige coordinación.
Productores publican hechos y consumidores reaccionan.
Conviene para reacciones y propagación; no para cada colaboración local.
Procesamiento dividido en transformaciones encadenadas:
input → validate → normalize → enrich → persistAdecuado para ETL, compiladores y procesamiento de medios.
Un núcleo estable carga capacidades extensibles.
core
├── plugin ventas
├── plugin facturación
└── plugin reportesUn mediador conecta y enruta componentes. Brokers de mensajes, RPC o integración reducen conocimiento de ubicación, pero se convierten en infraestructura crítica.
Distribuye estado y procesamiento en memoria para evitar un cuello central bajo cargas extremas. Aporta escalado, pero exige particionamiento, consistencia, recuperación y operación avanzada. Es una respuesta especializada, no una arquitectura inicial común.
Unidad de ejecución administrada por plataforma y activada por eventos.
Es un modelo operativo que puede combinarse con otros estilos.
¿Qué cualidades son prioritarias?
¿Los límites son conocidos o todavía cambian?
¿Existe necesidad real de autonomía y ownership?
¿El equipo puede manejar red, brokers, trazas, recuperación y múltiples pipelines?
¿Puede comenzarse con una opción simple que conserve seams?
¿Qué carga, fallos o cambios justifican la complejidad?
DomiSys inicial
equipo: pequeño
dominio: en evolución
transacciones: importantes
escala: moderada
operación distribuida: limitada
opción coherente:
monolito modular + capas/hexagonal dentro de módulos
+ eventos internos selectivosMicroservicios podrían aparecer después si existen equipos, escala o aislamiento diferenciados.
Los estilos operan en escalas distintas:
La combinación debe conservar un modelo mental comprensible. Mezclar estilos sin límites claros produce complejidad accidental.
Independencia total, consistencia fuerte y latencia mínima entre regiones no pueden maximizarse simultáneamente. Prioriza escenarios.
Puede ser válido por aislamiento regulatorio o cargas muy distintas, pero el costo debe estar respaldado.
Una unidad de despliegue puede escalar horizontalmente. Escala no implica automáticamente servicios.
Puede aumentar riesgo de seguridad y combinaciones. Considera configuración y feature flags antes de código arbitrario.
Monolito modular, microservicios y arquitectura evolutiva profundiza en la decisión de topología y en cómo migrarla sin convertirla en una apuesta irreversible.