Arquitectura vs. Diseño de software
Nivel básico — distinguir con precisión entre decisiones arquitectónicas y decisiones de diseño para intervenir en el nivel correcto.
El problema
Los equipos confunden constantemente decisiones de diseño con decisiones arquitectónicas. Un desarrollador senior propone "refactorizar la arquitectura" cuando en realidad quiere cambiar un patrón interno de un módulo. O al revés: el equipo toma una decisión que parece local, pero tiene implicaciones que nadie previó.
Caso típico: un equipo elige un ORM concreto "porque es más fácil". Seis meses después, esa elección ha acoplado toda la capa de persistencia a un proveedor específico — migrar a otra base de datos exige reescribir el 40% del código. // una decisión que parecía de diseño resultó ser arquitectónica
La distinción: coste de cambio
Arquitectura y diseño no son dos cajas separadas — es un espectro, y el eje es el coste de revertir la decisión.
Arquitectónicas
- Alto coste de cambio
- Afectan a varios componentes o equipos
- Ej: estilo (monolito vs. microservicios), protocolos entre servicios, persistencia, deployment
Zona gris
- Depende del contexto
- Ej: framework de UI, elección de base de datos
- Pregunta clave: ¿está abstraído detrás de una interfaz o expuesto directamente?
Diseño
- Bajo coste de cambio
- Localizadas en un componente
- Ej: patrones internos (Factory, Strategy, Observer), estructura de clases
Cuándo aplicarlo
| Trátalo como arquitectura si... | Trátalo como diseño si... |
|---|---|
| Requiere coordinación entre equipos para cambiar | Un desarrollador puede cambiarlo solo |
| Tiene implicaciones de coste o licencia | Es intercambiable sin impacto externo |
| Define el contrato entre componentes | Define la implementación interna |
| Afecta atributos de calidad del sistema completo | Afecta solo legibilidad/mantenibilidad local |
Es fácil clasificar "todo como arquitectura" cuando algo parece complejo, o "todo como diseño" cuando se subestima el acoplamiento real. Ninguna de las dos es el criterio — el único test válido es: ¿cuánto costaría revertir esto dentro de 6 meses?
Practica: clasifica estas 10 decisiones
Sistema de referencia: e-commerce con frontend React, API en Node.js, PostgreSQL e integración con Stripe. Para cada decisión, marca [A] Arquitectura o [D] Diseño y justifica con el criterio de coste de cambio.
- Usar PostgreSQL en lugar de MongoDB
- Implementar el patrón Repository en la capa de datos
- Exponer la API como REST en lugar de GraphQL
- Usar el patrón Strategy para calcular descuentos
- Comunicación síncrona (HTTP) vs. asíncrona (mensajería) entre servicios
- Estructura de carpetas del proyecto frontend
- Usar Kubernetes para orquestación de contenedores
- Implementar caché con Redis para sesiones
- Usar TypeScript en lugar de JavaScript
- Separar el monolito en microservicios