Definición: La arquitectura de software es la estructura fundamental de un sistema que define sus componentes, las relaciones entre ellos, y los principios que guían su diseño y evolución. Es el "plano" que determina cómo se organiza y comporta el software.
— Fuente: NERVICO, Consultoría de Desarrollo de Software
Qué es la Arquitectura de Software
Si el código es lo que hace que el software funcione, la arquitectura es lo que hace que el software siga funcionando cuando crece, cambia y evoluciona. Es el conjunto de decisiones estructurales que afectan a todo el sistema.
Una buena arquitectura no se nota. Una mala arquitectura se nota cada vez que intentas hacer un cambio.
Componentes de una Arquitectura
Componentes
Los "bloques" que forman el sistema: servicios, módulos, bases de datos, APIs, interfaces de usuario. Cada componente tiene una responsabilidad específica.
Conectores
Cómo se comunican los componentes: APIs REST, colas de mensajes, eventos, llamadas directas. La elección del conector afecta al acoplamiento y la escalabilidad.
Restricciones
Las reglas que limitan cómo pueden interactuar los componentes. Por ejemplo: "el frontend nunca accede directamente a la base de datos" o "todos los servicios deben autenticarse".
Patrones Arquitectónicos Comunes
Monolito
Todo el código en una única aplicación. Simple de empezar, puede volverse difícil de mantener cuando crece. No es malo por defecto — muchos proyectos exitosos son monolitos bien estructurados.
Microservicios
Sistema dividido en servicios pequeños e independientes. Cada servicio se despliega por separado. Mayor complejidad operativa, pero mejor escalabilidad y autonomía de equipos.
Serverless
Funciones que se ejecutan bajo demanda sin gestionar servidores. Ideal para cargas variables. Puede generar vendor lock-in y es difícil de depurar.
Event-Driven
Componentes que se comunican mediante eventos. Desacoplamiento alto, pero más difícil de razonar sobre el flujo de datos.
Por Qué la Arquitectura Importa
- Escalabilidad: Una arquitectura pensada permite crecer sin reescribir todo.
- Mantenibilidad: Código organizado es código que se puede cambiar sin miedo.
- Rendimiento: Las decisiones arquitectónicas afectan directamente a la velocidad.
- Costes: Una mala arquitectura genera trabajo extra en cada cambio.
- Onboarding: Equipos nuevos entienden más rápido un sistema bien estructurado.
Cuándo Pensar en Arquitectura
Siempre, pero con proporcionalidad. Un MVP no necesita microservicios. Un sistema con millones de usuarios no puede ser un script de 500 líneas.
La arquitectura debe evolucionar con el producto. Lo importante es tomar decisiones conscientes y documentarlas, no acertar a la primera.
Señales de Problemas Arquitectónicos
- "Cada cambio pequeño rompe algo inesperado"
- "No podemos desplegar sin parar todo el sistema"
- "Necesitamos 3 meses para añadir una feature simple"
- "Nadie entiende cómo funciona esta parte"
- "No podemos escalar sin reescribir todo"