La arquitectura de software es una de las disciplinas más importantes dentro del ámbito del desarrollo web. Consiste en la estructura base que los desarrolladores utilizarán para luego ir encajando las distintas piezas que conforman un sistema determinado.
En este artículo vamos a conocer en más detalle en qué consiste y también los tipos principales que hay. Pero dado que la confusión entre términos es frecuente en este campo, haremos una comparativa con el diseño de software y los patrones más utilizados.
De acuerdo con el Software Engineering Institute (SEI), la arquitectura de software hace referencia a "las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos”.
En otras palabras, se refiere a la estructura que debe tener un software, las partes que se van a construir y la forma en que vamos a unirlas y combinarlas para poder trabajar con ellas. Algo así como un plano que servirá de guía para el posterior desarrollo técnico y que facilitará la comunicación entre los diferentes perfiles profesionales que deban trabajar sobre él.
Pero, ¿qué función tiene la arquitectura de software? Son varias. En primer lugar, los desarrolladores del software sabrán cómo se integran todos los componentes. Por ejemplo, la definición de los módulos, las interfaces o la comunicación entre estas. Una segunda función es la de establecer principios y pautas que irán guiando el resto de decisiones sobre desarrollo y diseño. Además de ser un software de calidad, debe ser también seguro, escalable y fácil de mantener.
Puesto que hemos dicho que se trata de un plano o guía para los desarrolladores y resto de personas que deban trabajar con él, puede dar la sensación de que solo hay una forma de crearlo. Sin embargo, los tipos de arquitectura de software son múltiples. A continuación te dejamos los principales:
Este tipo tiene la particularidad de que, en realidad, no es arquitectura. Forma parte de los inicios de las aplicaciones web. Es decir, cuando estas se programaban desde el lado del servidor y no en el front-end development. Recibe este nombre porque se mezclaban varios tipos de funcionalidades. La consecuencia fue que, a medida que las aplicaciones crecían, se dificultaban la programación, la legibilidad y el mantenimiento.
La arquitectura por capas nació para corregir los problemas que se presentaban con la arquitectura spaghetti. Para ello, se crearon varias capas; cada una de ellas con diferentes usos. Por ejemplo, una se encarga de la visualización de datos, otra del acceso a la base de datos, etc. De esta manera, al repartir las funciones en capas distintas, se facilita el trabajo con todas ellas.
La arquitectura hexagonal aísla las entradas y salidas de aplicación de la lógica interna de la aplicación. Gracias a este aislamiento, se generan partes independientes que no dependen de los cambios externos. Por tanto, estas podrían modificarse de forma individual, sin afectar al resto.
La arquitectura Model-View-Controller (MVC) es un patrón de diseño que separa una aplicación en tres componentes principales, que son:
- Modelo (Model). Este representa los datos y la lógica de negocio del sistema. Se encarga del acceso a los datos almacenados, ya sea en una base de datos o en otros medios. También define las reglas de negocio que se deben cumplir.
- Vista (View). Esta capa se encarga de la presentación de los datos. Por tanto, interactúa con el usuario, muestra la información y recibe la entrada. Se diseña para que sea independiente del modelo. Es decir, que, como en la hexagonal, se puede cambiar sin afectar a los datos subyacentes.
- Controlador (Controller). Es el intermediario entre los dos componentes anteriores. Procesa las solicitudes o entradas del usuario; las procesa y realiza las operaciones necesarias en el modelo, como por ejemplo, actualizarlo, y decide qué vista es la que se mostrará después con los resultados.
La arquitectura de microservicios es un estilo arquitectónico en el que una aplicación, por lo general compleja, se divide en un conjunto de servicios pequeños. Estos son independientes y autónomos. Por tanto, cada microservicio es responsable de una funcionalidad específica y puede ser desarrollado, desplegado y escalado de manera independiente al resto.
También se caracteriza por la descentralización; los equipos trabajan con los microservicios separando cada uno de ellos. Hasta el punto de que pueden, incluso, trabajar con diferentes lenguajes de programación y tecnologías en cada uno. En cuanto a la comunicación entre ellos, lo hacen con APIs (Interfaces de Programación de Aplicaciones), que usan protocolos ligeros como HTTP/REST o mensajería basada en eventos.
La arquitectura monolítica sigue un enfoque tradicional, donde las funcionalidades de una aplicación se desarrollan y despliegan como una única unidad. Esto es, que todos los componentes de la aplicación, como la interfaz de usuario, la lógica de negocio o el acceso a los datos, están integrados en un solo programa o código base.
También, durante los ciclos de lanzamiento, el despliegue es de la aplicación al completo, que si bien simplifica su gestión, también dificulta los cambios en alguna parte concreta. Lo mismo sucede con el mantenimiento; es más sencillo al comienzo, pero a medida que crece la aplicación, si un cambio en un módulo afecta al resto, se producirán errores. Por eso, solo se usa en aquellas que son pequeñas o que necesitan un desarrollo inicial rápido.
Un concepto similar a la arquitectura y con la que a menudo se confunde es el diseño de software. Aunque ahora veremos una explicación y sus funciones para diferenciarlo de aquella, puedes profundizar en los conocimientos al estudiar desarrollo web full stack.
Dijimos que la arquitectura de software es la base estructural de este y la que sirve de referencia para el posterior desarrollo. El diseño de software sería el encargado de los detalles técnicos, que son necesarios para implementar dicha estructura. Los dos son imprescindibles para llegar a la versión final, pero trabajan en diferentes etapas del ciclo de vida del software y niveles.
La función principal del diseño es especificar todos los detalles para la implementación de cada uno de los componentes individuales del sistema, como los algoritmos, interacciones entre módulos o estructuras de datos. Pero también se encarga de dividir al sistema en módulos más pequeños, para facilitar el desarrollo y el mantenimiento; lo optimiza, en términos de uso de recursos o rapidez de ejecución, para mejorar la eficiencia y el rendimiento, y documenta en detalle cómo es la construcción del software.
Si volvemos a la arquitectura, ahora se puede ver con mayor claridad que esta opera a un nivel más abstracto, dado que mira la estructura global y la integración de los componentes principales, para asegurarse de que se cumplen todos los requisitos necesarios. Por el contrario, el diseño se centra en los detalles de la implementación ya definidos y en la construcción de los componentes.
El diseño de software también cuenta con varias formas de trabajar. Las más comunes son las siguientes:
Se centran en la creación de objetos para el sistema, con independencia de cómo se hayan creado, su composición o su representación. Por ejemplo, Singleton, que da una sola instancia, pero con acceso global, o Factory Method, que define una interfaz para el objeto, pero sin decidir las instancias, que se eligen en las subclases.
Otro de los patrones de diseño de software son los estructurales. Se encargan de la composición de objetos o clases y de que las entidades se combinen correctamente. Algunos ejemplos son Adapter, que hace que clases con interfaces incompatibles puedan trabajar juntas, o Decorator, que añade responsabilidades adicionales a un objeto de forma dinámica para extender funcionalidades.
Estos patrones se centran en la comunicación y en la asignación de responsabilidades entre objetos. Destacan Observer, que define la dependencia entre objetos para que cuando uno cambia, sus dependientes se actualicen automáticamente, o Strategy, que define una familia de algoritmos, encapsula cada uno y los hace intercambiables, para que aquellos puedan variar sin importar quién lo utiliza.
Con esta explicación, ya deberías comprender la diferencia entre arquitectura de software y su diseño. Pero si quieres seguir aclarando dudas y descubriendo nuevos conceptos, puedes hacerlo con nuestros másteres.