Software Architecture
Explica la arquitectura de software como decisiones estructurales sobre límites, dependencias, datos, despliegue, operación y evolución del sistema.
La arquitectura de software no es una colección de patrones ni el dibujo inicial del sistema. Es el conjunto de decisiones estructurales que determina qué puede cambiar con facilidad, qué debe permanecer protegido y cómo se comportará el sistema cuando crezca, falle o sea operado por personas reales.
Todo sistema termina teniendo una arquitectura, aunque nadie la diseñe explícitamente. La diferencia es si esa estructura surge de decisiones conscientes o de acumulaciones accidentales.
La arquitectura organiza elementos que afectan a muchas partes y que suelen ser costosos de cambiar:
Una forma útil de visualizarla es:
problema y objetivos
↓
drivers y restricciones
↓
atributos de calidad prioritarios
↓
límites, responsabilidades y datos
↓
decisiones y trade-offs
↓
código, infraestructura y operación
↓
evidencia, aprendizaje y evoluciónLa arquitectura no vive únicamente en la parte superior del diagrama. Se manifiesta en imports, contratos, tablas, pipelines, permisos, métricas, ownership y procedimientos de recuperación.
Cuando un sistema es pequeño, casi cualquier estructura parece funcionar. El equipo puede recordar dónde vive cada regla, coordinar cambios hablando directamente y corregir inconsistencias manualmente.
El problema aparece cuando aumentan:
Sin decisiones estructurales claras, el sistema acumula dependencias implícitas. Una modificación en inventario termina afectando pedidos, pagos y reportes. Dos módulos escriben la misma tabla y ninguno puede garantizar sus invariantes. Un proveedor externo filtra sus tipos por toda la aplicación. Un despliegue obliga a publicar todo el producto porque nadie sabe qué puede cambiar de manera independiente.
La arquitectura intenta reducir ese costo futuro. No elimina la complejidad esencial del dominio; evita que se multiplique mediante complejidad accidental.
Supón que DomiSys comienza con controladores que consultan directamente tablas y llaman proveedores:
HTTP controller
├── consulta inventario
├── modifica pedido
├── llama al proveedor de pagos
├── envía correo
└── genera respuestaAl principio parece rápido. Más adelante aparecen preguntas difíciles:
La ausencia de límites no evita decisiones; simplemente las oculta dentro de código difícil de cambiar.
No existe una lista universal. Una decisión es arquitectónica cuando cumple una o varias de estas condiciones:
Cambiarla afecta múltiples módulos, equipos, datos o procesos. Elegir cómo se identifica y propaga el tenant condiciona queries, cachés, jobs, archivos y eventos.
Cambiar una librería local puede ser sencillo. Migrar desde una base compartida sin ownership hacia bases separadas implica contratos, sincronización, backfills y operación temporal de dos modelos.
Elegir replicación asíncrona modifica latencia, disponibilidad y consistencia. Introducir caching cambia rendimiento, frescura y complejidad operacional.
Una API pública versionada limita la libertad de cambiar formatos. Una separación por bounded contexts condiciona módulos, equipos y ownership.
Seguridad, pagos, residencia de datos y recuperación ante desastres requieren más evidencia y revisión que una decisión reversible de UI.
La importancia depende del contexto. Usar PostgreSQL puede ser una decisión rutinaria en un sistema y crítica en otro si existen restricciones de licencia, residencia, volumen o conocimiento del equipo.
Arquitectura y diseño forman un continuo.
Responde preguntas como:
Responde preguntas como:
Una decisión local puede volverse arquitectónica si se replica o se convierte en restricción global. Por ejemplo, guardar fechas como texto parece un detalle hasta que afecta consultas, zonas horarias, integraciones y migraciones.
La arquitectura real es la que el sistema ejecuta y el equipo debe mantener.
documento: Orders no depende de Payments
código: Orders importa el SDK y las tablas de Payments
resultado: la arquitectura real es el acoplamiento del códigoPara que una decisión exista de verdad necesita mecanismos observables:
La documentación conserva intención y contexto. Los controles mantienen la estructura. La operación aporta evidencia de si la decisión funciona.
La arquitectura aparece en varias escalas que deben ser coherentes.
Capas, módulos, casos de uso, puertos, adaptadores y modelos.
APIs, eventos, timeouts, retries, compatibilidad, identidad y fallos parciales.
Ownership, invariantes, transacciones, replicación, retención y migraciones.
Topología regional, redes, despliegue, capacidad, secretos y recuperación.
Responsabilidad, comunicación, carga cognitiva, on-call y autonomía.
Una arquitectura técnicamente elegante puede fracasar si exige capacidades operativas que el equipo no posee.
No existe una arquitectura que maximice todo.
consistencia fuerte
→ menos estados ambiguos
→ mayor coordinación y posible latencia
microservicios
→ independencia potencial de despliegue
→ red, observabilidad y operación distribuida
abstracción adicional
→ protege una frontera cambiante
→ aumenta navegación y conceptosLa pregunta no es si una decisión tiene desventajas. Toda decisión relevante las tiene. La pregunta es si sus costos son aceptables para los drivers prioritarios.
Una arquitectura madura puede explicar:
Una aplicación necesita generar identificadores.
Decisión accidental:
import { randomUUID } from "node:crypto";
export function createOrder(input: CreateOrderInput) {
return {
id: randomUUID(),
...input,
};
}Para una aplicación pequeña, esto puede ser suficiente. No toda dependencia necesita una abstracción.
La decisión se vuelve arquitectónica cuando el identificador debe ser determinista en pruebas, compatible con un sistema legado o generado por otra autoridad. En ese contexto se introduce un contrato porque existe una frontera real, no porque una regla diga que toda función necesita una interfaz.
Un flujo de DomiSys puede requerir:
Estas responsabilidades obligan a decidir:
La arquitectura no dicta automáticamente microservicios. Un monolito modular puede mantener transacciones locales y publicar eventos mediante outbox. La topología se elige después de comprender las garantías.
Una buena arquitectura puede mejorar:
No garantiza:
La arquitectura es una hipótesis estructurada y revisable, no una promesa de ausencia de problemas.
Una decisión arquitectónica necesita una forma de comprobación.
Ocurre cuando el equipo decide “usar microservicios” o “aplicar Clean Architecture” antes de conocer drivers. Produce estructuras ceremoniales o costos que no resuelven un problema real.
Se detecta cuando nadie puede explicar qué escenario de calidad justifica la decisión.
Más servicios, capas o repositorios no significan mejores límites. La complejidad debe comprar una capacidad concreta.
El sistema paga hoy por problemas hipotéticos. La alternativa es conservar seams y observabilidad que permitan evolucionar cuando aparezca evidencia.
Un diagrama que no coincide con imports, datos, despliegue o ownership se vuelve decoración. Corrige conectando decisiones con controles y responsables.
Los drivers cambian. Registra señales de revisión y rutas de migración para decisiones costosas.
Profundiza cuando existen:
Mantén el diseño ligero cuando el producto es pequeño, reversible y de bajo riesgo. Ligero no significa inexistente: todavía deben estar claros el propósito, los límites centrales, los datos y las decisiones costosas.
domain no demuestra que el dominio esté protegido?Drivers arquitectónicos y restricciones enseña a identificar las fuerzas concretas que justifican una decisión estructural y evita diseñar a partir de preferencias técnicas.