El Significado de Arquitectura
Llegados a este punto, se nota que existe una relación más significativa entre arquitectura y componente, por lo que se puede realizar una mejor definición:
La arquitectura de un sistema de software es la forma que se le da a un sistema dividido en componentes, especificando su disposición e interacción entre estos componentes.
Esta arquitectura no es rígida y cambia a lo largo del tiempo debido a cambios en los requisitos, criterios de diseño y otras circunstancias, por lo que representa un equilibrio constante.
- Soporta el ciclo de vida del sistema: Apunta a facilitar las fases de desarrollo, despliegue, operación y mantenimiento.
- No se enfoca en los detalles operativos del sistema: Guarda poca relación con el funcionamiento del sistema, solo a un nivel pasivo y cosmético.
- Mantiene las opciones abiertas: Frente a los objetivos cambiantes, podemos recurrir a los principios de diseño (Principios SOLID y Principios de Componentes) con el fin de mantener la máxima flexibilidad y tener diversas alternativas a nuestra disposición.
- Una arquitectura descompone el sistema en componentes: Esta descomposición garantiza la estabilidad y la integridad del sistema, al tiempo que permite a los equipos trabajar de forma independiente en cada uno de los componentes.
-
Una arquitectura considera los desafíos del despliegue desde la etapa inicial: La elección de un alto nivel de despliegue sin haber considerado previamente todos los aspectos puede resultar en un despropósito.
-
Una arquitectura facilita el despliegue inmediato: La arquitectura no depende de los archivos de configuración ni tampoco de la organización de directorios o archivos.
La operación se puede analizar desde 2 perspectivas: rendimiento de la operación y esfuerzo cognitivo.
- Una arquitectura tiene poca relación con el rendimiento de la operación: La optimización del rendimiento es un detalle que pueden permitirse los componentes bien aislados, y se puede solucionar agregando más hardware y cambiando entre las distintas estrategias de despliegue a medida que cambien las necesidades operativas del sistema.
- Una arquitectura se relaciona más con el esfuerzo cognitivo: Entender lo que hace el sistema es parte crítica a nivel de operación e implica destacar casos de uso, funciones y comportamientos clave, visibles para los desarrolladores.
- Una arquitectura reduce el riesgo al agregar funciones o reparar defectos: La descomposición en componentes bien aislados facilita las tareas de mantenimiento.
Una arquitectura divide el sistema en capas horizontales y verticales para:
- Promover el desarrollo independiente: Permite la organización de equipos de desarrollo para abordar cada componente de forma independiente.
- Promover la implementación independiente: Permite cambiar capas horizontales o capas verticales(casos de uso) de manera simple.
Una arquitectura no son detalles de despliegue, los componentes pueden estar desacoplados a tal grado que puedan cambiar entre los distintos niveles (fuente, despliegue y servicio). Por lo tanto, una buena arquitectura permitirá avanzar y retroceder entre los distintos niveles.
En consecuencia, si creías que los monolitos, las unidades desplegables independientes, la Arquitectura Orientada a Servicios (SOA) y los microservicios son arquitecturas o forman parte de tu arquitectura, pues en realidad no lo son y actúan más como medios para respaldar la demanda que requiere el sistema, es decir, son estrategias de despliegue.
En este nivel, controlamos las dependencias de los módulos de código fuente para mantenerlos desacoplados. Asimismo, todos estos módulos se integran en un solo ejecutable que opera en un solo espacio de direcciones, conocido como Monolito.
-
Unidad grande y única estrechamente acoplada: Humorísticamente, el "Monolito" se representa como un "plato de espagueti" para destacar los problemas de falta de modularidad y la dificultad para escalar y mantener el código en proyectos de gran tamaño. Sin embargo, un buen diseño de monolito mantiene una estructura modular y organizada, incluso dentro de una única unidad; por lo que los problemas anteriores son producto de un mal diseño.
-
Monolito Modular: Este concepto parece un parche a la idea anterior, porque justifica la idea de que un monolito carece de modularidad, cuando en realidad la capacidad de ser modular es propia de una buena arquitectura y no está definida por una estrategia de despliegue. Lo que sí es rescatable en este punto es la capacidad de encapsular partes del código para hacer una distinción entre lo que se quiere mostrar y aquello que no; por ejemplo, encontramos estas características presentes en:
- Java 9 y su sistema de módulos
- Kotlin con su palabra clave internal
- Gradle y su sistema de módulos
En este nivel, algunos componentes están desacoplados en unidades desplegables independientes, por lo que se ejecutan en otros procesos diferentes y se comunican a través de comunicación entre procesos (IPC), sockets o memoria compartida.
En este nivel, los componentes han sido reducidos a simples unidades de ejecución independientes que se comunican mediante paquetes de red.
