Empecemos por lo básico: ¿qué es la arquitectura de software?

 

La mayoría de los sistemas modernos están conformados por un grupo de componentes que colaboran entre sí para cumplir un objetivo.

 

Algunos de estos componentes pueden ser bases de datos, repositorios documentales, servicios que ejecutan la lógica del negocio y una interfaz para que los usuarios puedan interactuar con los servicios, a través de aplicaciones web o móviles.

 

La arquitectura de software de un sistema es una representación abstracta de los componentes que lo constituyen, sus responsabilidades y las relaciones entre ellos (usos y dependencias). 

 

Es importante recordar que la arquitectura es independiente de la tecnología que se utiliza para la construcción y no representa algún framework o lenguaje específico. 

 

Así como sucede con un edificio, la arquitectura de software se considera el plano de la aplicación que se va a construir. 

 

Arquitectura de aplicaciones de alto nivel

 

La arquitectura de software está formada por un conjunto de patrones. Los patrones son formas probadas para realizar una operación correctamente. La arquitectura de un sistema se representa mediante diferentes tipos de diagramas que son interpretados por los desarrolladores durante la construcción.

 

Recuerda, los patrones se van creando a través de los años gracias a las buenas prácticas.  

 

Hoy nos enfocaremos en el patrón de arquitectura multicapa. Para evitar confusiones es importante señalar que en inglés existen los conceptos de arquitectura multitier y multilayer. En español, la traducción para ambos es arquitectura multicapa. Veamos en qué se diferencian:

 

• Multi-tier: Es la separación de los elementos en múltiples capas físicas. Cada capa corresponde a una máquina física o virtual en la cual se ejecuta algún componente del sistema.
  

• Multi-layer: Es la separación lógica de responsabilidades en múltiples capas. Cada capa es un conjunto de clases, paquetes o subsistemas que tienen responsabilidades. Estas capas están organizadas de forma jerárquica, unas encima de otras, y las dependencias siempre van abajo. 

Es decir, una capa concreta dependerá solamente de las capas inferiores, pero nunca de las superiores. 

 

El patrón de arquitectura multicapa para una aplicación se refiere a la separación lógica de responsabilidades dentro de la aplicación, no a la separación física. 

 

Un ejemplo: La arquitectura hexagonal

 

Ahora que sabemos qué es una arquitectura multicapa, veamos un ejemplo de ella, la arquitectura hexagonal y sus diferentes capas.

 

La arquitectura hexagonal, también conocida como arquitectura de Puertos y Adaptadores (Ports And Adapters), fue definida por Alistair Cockburn, que es uno de los impulsores de la metodología de desarrollo ágil.

 

 

A diferencia de la arquitectura  multicapa tradicional (que va de arriba-abajo), esta arquitectura va desde afuera hacia adentro, hacia los objetos de dominio. 

 

El hexágono es una forma sencilla de describir el núcleo de la aplicación, donde están los objetos de dominio y casos de uso que operan con ellos, además de los puertos de entrada y salida que proporcionan una interfaz al mundo exterior.

 

 

Esta arquitectura pone en el centro del sistema toda la lógica propia del dominio (lo que vemos en amarillo) y define unas fronteras muy claras con sus respectivos mecanismos de comunicación (los elementos verdes). 

 

También define la comunicación con el exterior (elementos azules), ya sea de entrada o salida. Así se consigue que el core lógico de la aplicación no se contamine ni dependa en ningún momento de los detalles concretos del acceso a bases de datos, comunicación con otros servicios o de la interacción del usuario. 

 

Esta arquitectura permite, por ejemplo, crear una aplicación para que funcione sin ninguna interfaz de usuario o alguna base de datos, lo que habilita la ejecución de pruebas de regresión totalmente automatizadas, trabajar aunque la base de datos no esté disponible y también integrar aplicaciones de forma limpia.

 

Los objetos de dominio

 

Son el elemento vital de la aplicación, los elementos que le dan sentido al sistema. Son conceptos definidos a partir de los requerimientos y no dependen de elementos externos.

 

Gracias a esto, los cambios realizados en otras capas no los afectan. Evolucionan solamente de acuerdo a las necesidades del negocio. 

 

Esta evolución independiente hace que la arquitectura hexagonal sea perfecta para el diseño de sistemas basados en el dominio.

 

Casos de uso

 

Son descripciones abstractas de lo que lo que realiza el sistema, generalmente es un relato en prosa, con una serie de pasos en los que se describe la interacción de un usuario (u otro sistema) con la aplicación.

 

En el estilo de arquitectura hexagonal tiene sentido construir los casos de uso como elementos de software que forman parte del core de la aplicación.

 

En este sentido, el caso de uso es una clase que maneja todo a su alrededor, o más bien todo lo que tiene que ver con un caso de uso en concreto.

 

Por ejemplo, consideremos el caso de uso típico “Transferencia de fondos” en una aplicación bancaria. 

 

Podemos crear una clase llamada “TransferenciaBancaria” que permita transferir dinero de una cuenta a otra. 

 

El código contendrá todas las validaciones y la lógica de las reglas de negocio que son específicas del caso de uso y por lo tanto no se pueden implementar dentro de los objetos de dominio. Todo lo demás se delega a los objetos de dominio (objeto cuenta, objeto transferencia, etc).

 

Al igual que los objetos de dominio, una clase de un caso de uso no depende de componentes externos. Cuando se necesita algo que esté fuera del hexágono creamos un puerto de salida.

 

Fronteras claras, independencia y comunicación

 

 

Como lo vemos en la imagen, el core tiene fronteras claramente definidas, que permiten la independencia del exterior, permitiendo que una aplicación sea manejada igualmente por usuarios, otras aplicaciones, pruebas automatizadas, etc. 

 

También se puede hacer una prueba de forma aislada de sus eventuales clientes y bases de datos en tiempo de ejecución.

 

Por último, la comunicación con el exterior se realiza a través de puertos y adaptadores que se encargan de la conversión de datos para que dentro de las fronteras, donde está el core de la aplicación, todo se maneje en lenguaje del dominio del negocio, sin conceptos ajenos.

 

¿Cómo definimos las fronteras?

 

Las fronteras se definen a través de los puertos. Podemos decir que el core del sistema es la capa interna y los adaptadores son la capa externa o exterior, que se comunican con la capa interna a través de los puertos.

 

A medida que llegan mensajes del mundo exterior, algún adaptador convierte este mensaje en otro que sea entendible por la aplicación (objeto de dominio) y se lo pasa a través de un puerto primario o de entrada. La aplicación ignora la naturaleza del sistema que envió el mensaje. 

 

Por otro lado, cuando la aplicación tiene un mensaje que enviar, lo hace a través de un puerto, pero en este caso a través de un puerto secundario (o de salida), hacia a un adaptador.

 

Este adaptador transforma el mensaje en caso necesario para que el receptor reciba la información de forma adecuada. 

 

De este modo logramos que la aplicación tenga una interacción sólida con todos sus adaptadores, pero sin conocer absolutamente nada de lo que está fuera, es decir, al otro lado de los adaptadores.

Te puede interesar: ¡Aplica a nuestras vacantes! Mira los empleos disponibles

 

Tipos de adaptadores

 

Como ya lo mencionamos, la comunicación se realiza a través de los adaptadores, que forman la capa exterior de la arquitectura hexagonal. No forman parte del core, pero interactúan con él.

 

Los adaptadores primarios, o de entrada, llaman a los puertos de entrada para ejecutar alguna acción. Un adaptador de entrada podría ser una interfaz web, por ejemplo. 

 

Cuando un usuario hace click en algún botón o algún link de la aplicación web, el adaptador web llama a un determinado puerto de entrada que, a su vez, llama al caso de uso correspondiente.

Por otro lado, los casos de uso del core llaman a los adaptadores secundarios o de salida y pueden por ejemplo proporcionar acceso a una base de datos. Un adaptador de salida implementa la interfaz del puerto de salida. 

 

Si necesitamos acceder a una base de datos diferente, agregamos un nuevo adaptador que implementa las mismas interfaces de puerto de salida que el anterior pero quizá con otro driver, no se modifica el caso de uso ni el puerto, solamente se crea el adaptador nuevo.

 

Si bien la arquitectura se llama hexagonal no tiene porqué definirse 3 puertos con dos adaptadores cada uno, el nombre hexa no tiene que ver con la cantidad, el hexágono es solo una representación para entender mejor esta arquitectura.

 

Como todo sistema, depende del caso concreto. Los extremos están en tener un único puerto para todo el sistema (arquitectura monolítica) o tener un puerto diferente por cada una de las funcionalidades (antipatrón de microservicios). 

 

Debemos tener un diseño adecuado que equilibre la limpieza de la arquitectura, el rendimiento de la aplicación y también la administración de la aplicación.

 

Algo muy importante es que, siendo purista, en la arquitectura hexagonal no hablamos de cómo implementar la lógica de negocio como tal (los casos de uso), sino que manejamos todo como si fueran solamente dos capas: los adaptadores que están fuera del hexágono por una parte y los puertos y la lógica de negocio como otra.

 

La capa superior será lo que está fuera y la capa inferior lo que está dentro del hexágono, tomando la dependencia de arriba a abajo.

 

Dentro del core se podrá diseñar los elementos necesarios que permitan cumplir con los requerimientos.

 

En resumen…

 

• Dentro del hexágono o capa interior tenemos los elementos core de la aplicación: elementos de dominio y componentes que ejecutan casos de uso.

 

• Los puertos primarios son el mecanismo que permite acceder al core desde el exterior, enviando objetos del dominio hacia la aplicación.

 

• Los adaptadores primarios permiten la comunicación desde el exterior, utilizando los puertos primarios para conectarse con el interior de la aplicación.

 

• Los puertos secundarios son interfaces para comunicarse con otros servicios, ya sean bases de datos, servicios de correo, etc.

 

• Los adaptadores secundarios son la implementación de estas interfaces que implementan la lógica específica de conexión. 

 

Recuerden, la arquitectura puede tener tantos puertos y adaptadores como se requiera en el proyecto, el dibujo es solo una orientación. Si quieres profundizar en el tema puedes ver la siguiente capacitación.

Apiux Jobs