La arquitectura de software se ocupa de las decisiones estructurales más importantes de un sistema. Define sus componentes principales, cómo se relacionan, cómo se despliegan, qué tecnologías relevantes se usan y cómo se satisfacen atributos de calidad como seguridad, rendimiento, escalabilidad y mantenibilidad.
Mientras el diseño de bajo nivel puede enfocarse en clases, funciones o módulos concretos, la arquitectura mira el sistema con una perspectiva más amplia. Se pregunta cómo organizar la solución para que pueda cumplir sus objetivos actuales y evolucionar razonablemente.
En este tema veremos una introducción a la arquitectura de software y a las decisiones que suelen formar parte de ella.
La arquitectura de software es la organización fundamental de un sistema: sus componentes principales, sus responsabilidades, sus relaciones, sus principios de diseño y las decisiones que condicionan su evolución.
Puede incluir:
Diseño y arquitectura están relacionados. La diferencia no siempre es rígida, pero puede entenderse por nivel de impacto y alcance.
| Diseño | Arquitectura |
|---|---|
| Organiza responsabilidades en partes concretas. | Define la estructura general del sistema. |
| Puede enfocarse en clases, módulos, funciones o pantallas. | Se enfoca en componentes principales, tecnologías, integración y despliegue. |
| Algunas decisiones son más fáciles de cambiar. | Muchas decisiones son costosas de revertir. |
| Ejemplo: cómo validar una reserva dentro de un módulo. | Ejemplo: si el sistema será monolítico, distribuido o basado en servicios. |
Una forma simple de pensarlo: la arquitectura contiene las decisiones de diseño más importantes y de mayor alcance.
Un componente arquitectónico es una parte importante del sistema con una responsabilidad clara. Puede ser una aplicación web, una API, una base de datos, un servicio de autenticación, un módulo de pagos o un sistema externo.
Ejemplo de componentes en una tienda en línea:
La arquitectura debe aclarar qué hace cada componente y cómo se comunica con los demás.
Además de definir componentes, la arquitectura debe mostrar cómo se relacionan. La comunicación puede ser directa, mediante APIs, eventos, colas de mensajes, archivos, bases compartidas u otros mecanismos.
Al diseñar comunicación entre componentes conviene preguntar:
Las relaciones mal definidas pueden generar alto acoplamiento y fallas difíciles de diagnosticar.
La arquitectura está muy influida por los atributos de calidad. No alcanza con que el sistema tenga funcionalidades; debe cumplir condiciones de rendimiento, seguridad, disponibilidad, escalabilidad, mantenibilidad y operación.
| Atributo | Impacto arquitectónico posible |
|---|---|
| Rendimiento | Uso de caché, optimización de consultas, procesamiento asincrónico. |
| Seguridad | Autenticación, autorización, cifrado, auditoría y separación de permisos. |
| Disponibilidad | Redundancia, monitoreo, recuperación ante fallas y despliegues controlados. |
| Escalabilidad | Separación de componentes, balanceo de carga, colas y crecimiento horizontal. |
| Mantenibilidad | Modularidad, bajo acoplamiento, límites claros y documentación de decisiones. |
| Portabilidad | Independencia de plataforma, contenedores o configuración externa. |
Un estilo arquitectónico es una forma general de organizar un sistema. No es una receta exacta, pero ofrece ideas y restricciones comunes.
Algunos estilos conocidos son:
Elegir un estilo debe responder al contexto, no a una moda.
Una decisión común es si construir una aplicación monolítica o dividir el sistema en servicios. Ambas opciones pueden ser correctas según el caso.
| Enfoque | Ventajas | Riesgos |
|---|---|---|
| Monolito | Más simple de desarrollar, probar y desplegar al inicio. | Puede volverse difícil de modificar si crece sin modularidad interna. |
| Servicios separados | Permiten independencia de despliegue y escalado por componente. | Agregan complejidad de comunicación, operación, monitoreo y consistencia. |
Un error común es dividir en servicios demasiado temprano sin tener una necesidad clara. Otro error es mantener un monolito sin límites internos hasta que se vuelve inmanejable.
La arquitectura en capas organiza el sistema según niveles de responsabilidad. Un esquema habitual separa presentación, aplicación, dominio e infraestructura.
Este estilo ayuda a separar responsabilidades, aunque debe aplicarse con criterio. Crear capas que solo pasan datos sin aportar claridad puede agregar complejidad innecesaria.
Una decisión arquitectónica es una elección importante que condiciona el sistema. Conviene registrarla porque explica por qué el sistema se organizó de cierta manera.
Ejemplos:
Estas decisiones deben relacionarse con requisitos, restricciones y atributos de calidad.
En arquitectura casi siempre hay compromisos. Mejorar un atributo puede afectar otro. Por eso, las decisiones arquitectónicas deben discutirse en función del contexto.
| Decisión | Beneficio posible | Costo o riesgo posible |
|---|---|---|
| Dividir en microservicios | Escalado y despliegue independiente. | Mayor complejidad operativa y de comunicación. |
| Agregar caché | Mejor rendimiento. | Riesgo de datos desactualizados. |
| Centralizar autenticación | Control uniforme de acceso. | Dependencia crítica de un componente central. |
| Usar colas de mensajes | Mayor tolerancia a picos y desacoplamiento. | Más complejidad para monitorear y depurar. |
La arquitectura debe responder a requisitos funcionales y no funcionales. Muchas decisiones técnicas solo tienen sentido si se relacionan con una necesidad concreta.
Ejemplos:
Una arquitectura sin relación con requisitos puede ser técnicamente interesante, pero innecesaria o inadecuada.
La arquitectura debe comunicarse. No siempre hace falta un documento extenso, pero sí conviene registrar decisiones importantes, diagramas principales y razones.
Una documentación arquitectónica básica puede incluir:
La documentación debe mantenerse útil. Un diagrama desactualizado puede perjudicar más de lo que ayuda.
Una plataforma educativa en línea podría tener estos componentes:
Algunas decisiones arquitectónicas podrían ser:
La arquitectura no siempre se define completamente al inicio. En muchos proyectos evoluciona a medida que se aprende más sobre requisitos, usuarios, volumen, riesgos y restricciones.
Sin embargo, esto no significa ignorar la arquitectura. Algunas decisiones tempranas pueden facilitar o dificultar el crecimiento futuro.
Una arquitectura evolutiva busca:
Al trabajar con arquitectura suelen aparecer errores como:
Algunas buenas prácticas son:
La arquitectura de software organiza las decisiones estructurales más importantes de un sistema. Permite conectar necesidades funcionales y atributos de calidad con una estructura técnica capaz de sostener el producto en el tiempo.
Para quien comienza, la idea principal es esta: la arquitectura no es solo elegir tecnologías; es decidir cómo se organizará el sistema para cumplir sus objetivos y soportar su evolución.
En el próximo tema veremos construcción del software: código, estándares y revisión, pasando de decisiones de diseño y arquitectura a prácticas concretas de implementación.