MÁS ARQUITECTURA HEXAGONAL

 Frameworks (marcos) y Drivers (controladores).

La capa más externa generalmente se compone de marcos y herramientas como la Base de datos, el Framework, etc. Generalmente, no se escribe mucho código en esta capa que no sea el código de cola que se comunica con el siguiente círculo hacia adentro.

Esta capa es donde van todos los detalles. La web es un detalle. La base de datos es un detalle. Mantenemos estas cosas en el exterior donde pueden hacer poco daño.

¿Sólo cuatro círculos?

No, los círculos son esquemáticos. Puedes encontrar que necesitas más que estos cuatro. No hay una regla que diga que siempre debe tener solo estos cuatro. Sin embargo, la regla de dependencia siempre se aplica. Las dependencias del código fuente siempre apuntan hacia adentro. A medida que avanzas, el nivel de abstracción aumenta. El círculo más exterior es el detalle de hormigón de bajo nivel. A medida que avanza hacia el interior, el software se vuelve más abstracto y encapsula políticas de nivel superior. El círculo más interno es el más general.

Cruzando las fronteras

En la parte inferior derecha del diagrama hay un ejemplo de cómo cruzamos los límites del círculo. Muestra a los Controladores y Presentadores que se comunican con los Casos de Uso en la siguiente capa. Tenga en cuenta el flujo de control. Comienza en el controlador, se mueve a través del caso de uso y luego termina ejecutándose en el presentador. Tenga en cuenta también las dependencias del código fuente. Cada uno de ellos apunta hacia adentro hacia los casos de uso.

Normalmente resolvemos esta aparente contradicción usando el principio de inversión de dependencia. En un lenguaje como Java, por ejemplo, organizaríamos interfaces y relaciones de herencia de modo que las dependencias del código fuente se opongan al flujo de control en los puntos correctos a lo largo del límite.

Por ejemplo, considere que el caso de uso debe llamar al presentador. Sin embargo, esta llamada no debe ser directa porque eso violaría la Regla de dependencia: ningún hombre en un círculo exterior puede ser mencionado por un círculo interno. Así que tenemos el caso de uso, llamar a una interfaz (que se muestra aquí como Puerto de salida del caso de uso) en el círculo interno, y hacer que el presentador en el círculo externo lo implemente.

La misma técnica se utiliza para cruzar todos los límites en las arquitecturas. Aprovechamos el polimorfismo dinámico para crear dependencias de código fuente que se oponen al flujo de control para que podamos cumplir con la Regla de dependencia, sin importar en qué dirección vaya el flujo de control.

Fuentes: Libro gratuito Internet.