# Definición
La arquitectura de software no es simplemente "hacer una caja con flechitas". Es el diseño de más alto nivel de la estructura de un sistema. Comprende los elementos de software, sus relaciones y las propiedades de ambos.
En otras palabras, la arquitectura se trata de las decisiones difíciles de cambiar. Aquellas que, si se toman mal al principio, costarán mucho dinero y tiempo corregir más adelante.
# Architectural Drivers
¿Qué motiva una arquitectura? No diseñamos por capricho, sino para satisfacer necesidades. Estas necesidades se dividen en dos grandes grupos:
Requerimientos Funcionales
Lo que el sistema hace. Las tareas, servicios o funciones que debe realizar para el usuario final.
- Procesar un pago
- Generar un reporte
- Enviar una notificación
Atributos de Calidad (No Funcionales)
Cómo el sistema se comporta. Son las características que definen la calidad de la experiencia.
- Escalabilidad: ¿Soporta más usuarios?
- Disponibilidad: ¿Está siempre online?
- Seguridad: ¿Están los datos protegidos?
# Detalle de Atributos de Calidad
-
Rendimiento: Se enfoca en la eficiencia y los tiempos de respuesta ante estímulos o carga de trabajo.
-
Escalabilidad: Garantiza que el sistema pueda manejar un aumento significativo de carga sin degradar su servicio.
-
Disponibilidad: Mide la proporción de tiempo que el sistema está operativo y accesible para el usuario.
-
Seguridad: Protege la integridad, confidencialidad y disponibilidad de los datos frente a amenazas.
-
Mantenibilidad: Define qué tan fácil es corregir errores o evolucionar el código ante nuevos requisitos.
-
Usabilidad: Asegura que la interacción del usuario con el sistema sea intuitiva y eficiente.
-
Fiabilidad (Reliability): Garantiza que el sistema funcione correctamente y de forma consistente bajo condiciones específicas.
# Estructuras y Visiones
Un sistema de software es demasiado complejo para verlo desde un solo ángulo. Por eso usamos diferentes estructuras:
-
Estructura de Módulos: Cómo se organiza el código (en paquetes, clases, capas). Se enfoca en la mantenibilidad.
-
Componentes y Conectores: Cómo interactúan las piezas en tiempo de ejecución (servicios, bases de datos). Se enfoca en el rendimiento y disponibilidad.
-
Asignación (Allocation): Cómo el software se mapea a hardware o equipos de trabajo.
# Mediciones y Métricas: Lo que no se mide, no mejora
En el mundo de la arquitectura, las métricas no son solo números; son la evidencia que respalda nuestras decisiones técnicas. Medir nos permite transformar percepciones subjetivas (como "el sistema se siente lento") en datos objetivos y accionables.
Observabilidad y Monitoreo
No basta con saber si el sistema está "vivo". Necesitamos entender su estado interno. Esto incluye Telemetría (Logs, Métricas, Traces) para detectar cuellos de botella antes de que afecten al usuario.
Métricas Técnicas Clave
- Throughput: Cantidad de transacciones por segundo que el sistema procesa.
- Latencia: Tiempo que tarda una solicitud en ser procesada (p95, p99).
- Tasa de Error: Porcentaje de solicitudes que fallan sobre el total.
Además de las métricas de rendimiento, evaluamos la Deuda Técnica y el Acoplamiento. Un alto acoplamiento indica que cambiar una pieza romperá otras diez, lo que reduce la velocidad de entrega (Time to Market).
Definen el compromiso de disponibilidad con el negocio.
Simulan condiciones extremas para hallar el punto de quiebre.
Miden la eficiencia operativa del equipo de ingeniería.
# Comunicando la Arquitectura (Documentación)
Documentar no es "escribir por escribir". Es una herramienta de comunicación para alinear a los equipos y preservar el Contexto de las Decisiones. Una arquitectura sin documentación es una caja negra que nadie se atreve a tocar.
¿Por qué documentamos?
Alineación
Para que todos los desarrolladores remen en la misma dirección técnica.
Transferencia
Facilita el onboarding de nuevos integrantes al equipo.
Análisis
Permite evaluar el impacto de cambios antes de escribir una sola línea de código.
terminal ADRs y Diagramas Vivos
Hoy en día, evitamos los documentos estáticos de 200 páginas. En su lugar, usamos ADRs (Architecture Decision Records): registros cortos y versionados que explican por qué elegimos una tecnología sobre otra. Complementamos esto con Diagramas C4 (Contexto, Contenedores, Componentes, Código) que permiten hacer "zoom" en diferentes niveles de abstracción del sistema.
# Conclusión
La arquitectura de software es el puente entre los requerimientos den negocio y la implementación técnica. Un arquitecto no es solo el que sabe programar, sino el que sabe balancear los "trade-offs" (concesiones): para ganar escalabilidad, quizás deba sacrificar simplicidad.
La regla de oro
"Todo en la arquitectura de software es un trade-off. Si alguien te dice que una solución no tiene desventajas, probablemente no las ha encontrado todavía."