Principios arquitectónicos del sistema
Objetivo
Este documento define los principios arquitectónicos que guían el diseño, evolución y toma de decisiones en un sistema de software. Los principios funcionan como restricciones conscientes, no como recetas ni soluciones concretas.
Su propósito es:
- Reducir ambigüedad técnica
- Alinear decisiones a lo largo del tiempo
- Mantener coherencia incluso cuando el sistema crece o cambian las personas
Un principio arquitectónico no dice qué construir, sino cómo pensar cuando se construye.
Qué es un principio arquitectónico
Un principio arquitectónico es una regla de alto nivel que influye en múltiples decisiones técnicas.
Características clave:
- Es estable en el tiempo
- Aplica a todo el sistema
- Prioriza criterios sobre implementaciones
- Ayuda a decir “no” con argumentos técnicos
Ejemplo conceptual:
“Preferimos simplicidad explícita sobre abstracción prematura”
Esto no define una tecnología, pero sí orienta cientos de decisiones pequeñas.
Qué NO es un principio arquitectónico
No es:
- Un framework específico
- Un patrón impuesto sin contexto
- Una optimización local
- Una moda tecnológica
Si un “principio” deja de tener sentido cuando cambias de lenguaje o stack, probablemente no era un principio.
Por qué los principios importan
En sistemas reales:
- Las decisiones se toman de forma distribuida
- El contexto nunca es completo
- El tiempo presiona más que la perfección
Los principios actúan como campo gravitacional: no dictan el camino exacto, pero evitan desviaciones peligrosas.
Sin principios:
- Cada decisión se debate desde cero
- El criterio depende de la persona
- El sistema pierde identidad técnica
Principios arquitectónicos fundamentales
Los siguientes principios aparecen, explícita o implícitamente, en la mayoría de sistemas sostenibles.
1. Simplicidad consciente
La simplicidad no es falta de capacidad técnica; es una decisión deliberada.
Principio:
Preferir la solución más simple que funcione hoy y no limite mañana.
Implicaciones:
- Evitar abstracciones genéricas sin necesidad real
- Resolver el problema actual, no todos los futuros imaginados
- Entender que complejidad innecesaria es deuda técnica anticipada
La complejidad siempre aparece; la pregunta es si aparece por necesidad o por diseño.
2. Separación clara de responsabilidades
Cada parte del sistema debe tener un propósito claro y limitado.
Principio:
Una responsabilidad clara reduce el acoplamiento y facilita el cambio.
Implicaciones:
- UI no decide reglas de negocio
- Persistencia no define flujos
- Infraestructura no contamina dominio
Cuando una pieza “hace de todo”, el sistema se vuelve frágil, no flexible.
3. Modularidad como herramienta de cambio
La modularidad no existe para organizar carpetas, sino para permitir evolución.
Principio:
Los cambios deben afectar al menor número de módulos posible.
Implicaciones:
- Interfaces explícitas
- Dependencias controladas
- Módulos reemplazables sin reescritura global
Un módulo que no puede cambiarse de forma aislada no es realmente un módulo.
4. Tolerancia al cambio (no al caos)
El cambio es constante; la arquitectura debe asumirlo.
Principio:
Diseñar para cambiar decisiones, no para defenderlas eternamente.
Implicaciones:
- Preferir configuraciones sobre código rígido
- Evitar decisiones irreversibles tempranas
- Aislar lo volátil de lo estable
La arquitectura no debe congelar el sistema en el tiempo, sino permitir que aprenda.
5. Decisiones explícitas sobre implícitas
Lo implícito se olvida. Lo explícito se discute, se documenta y se mejora.
Principio:
Las decisiones importantes deben ser visibles y trazables.
Implicaciones:
- Uso de ADRs
- Convenciones documentadas
- Suposiciones declaradas
Un sistema lleno de decisiones implícitas es difícil de entender y peligroso de modificar.
6. Observabilidad como principio, no como extra
No se puede operar lo que no se puede observar.
Principio:
Todo componente relevante debe poder explicar su comportamiento.
Implicaciones:
- Logs con intención, no ruido
- Métricas alineadas a objetivos
- Errores comprensibles, no crípticos
La observabilidad no arregla problemas, pero permite reaccionar antes de que escalen.
7. Optimizar para el mantenimiento, no solo para la entrega
El software vive más tiempo del que se desarrolla.
Principio:
El costo dominante del software es su evolución, no su creación inicial.
Implicaciones:
- Código legible sobre código “ingenioso”
- Decisiones comprensibles por terceros
- Menor dependencia de conocimiento tribal
Un sistema que solo entiende quien lo escribió ya empezó a fallar.
Cómo usar estos principios en la práctica
Los principios arquitectónicos se usan cuando:
- Hay varias soluciones posibles
- El costo de decisión es alto
- La incertidumbre es significativa
No reemplazan:
- Análisis técnico
- Experimentos
- Prototipos
Los principios orientan, no sustituyen el pensamiento crítico.
Antipatrones comunes
- Convertir principios en dogmas
- Usarlos para bloquear discusión
- Invocarlos sin entender el contexto
- Contradecirlos sin reconocerlo
Un principio mal aplicado puede ser tan dañino como no tener ninguno.
Cierre conceptual
La arquitectura no es un diagrama ni un stack tecnológico. Es un conjunto de decisiones sostenidas en el tiempo.
Los principios arquitectónicos son la brújula que mantiene coherencia cuando:
- El sistema crece
- El equipo cambia
- El contexto evoluciona
Sin principios, la arquitectura deriva. Con principios claros, el sistema puede cambiar sin perder su forma.