ARQUITECTURA HEXAGONAL un par de conceptos

Principio de inversión de dependencia (DIP)

En el siguiente ejemplo, el DIP se aplicó al desacoplar nuestros casos de uso de los repositorios. Recordemos el DIP y luego navegaremos a través de un ejemplo:

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de las abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Veamos cómo apliqué este principio en el siguiente ejemplo:

En el lado izquierdo encontramos en rojo una aplicación en capas en la que DepositUseCase depende de la implementación de AccountSQLRepository. Es una forma acoplada de escribir código. En el lado derecho, en azul, al agregar un IAccountRepository y aplicar DIP, el AccountSQLRepository tiene su dependencia apuntando hacia dentro.

El DepositUseCase es el módulo de alto nivel que no depende de los detalles de la base de datos, sino que depende de la abstracción de IAccountRepository.

IAccountRepository es la abstracción que no depende de los detalles de la base de datos.

El AccountSQLRepository es el módulo de bajo nivel que depende de la abstracción IAccountRepository.

Esa es la idea principal detrás de la Arquitectura Hexagonal, siempre que nuestra aplicación requiera un servicio externo, usamos el puerto (una interfaz simple) e implementamos el Adaptador detrás de la abstracción.

Separación de preocupaciones (SoC)

Nuestra aplicación requiere algunas capacidades externas, pero a la aplicación no le preocupan los detalles de su implementación, solo sus abstracciones son visibles para la capa de la aplicación. Aplicamos SoC creando límites alrededor de los adaptadores y permitiendo que se desarrollen y prueben de forma aislada. Es una buena práctica tener paquetes diferentes para cada implementación de Adaptador.

Podríamos tener un Adaptador específico para una base de datos SQL y un Adaptador específico para el Almacenamiento de Azure, ambos podrían reemplazarse con poco esfuerzo. Esa es la idea detrás de la arquitectura hexagonal, mantener las opciones abiertas el mayor tiempo posible y la capacidad de retroceder si es necesario.

Todas las arquitecturas tienen el mismo objetivo común, que es la “separación de intereses”, para dar como resultado sistemas que son:

1.- Independientes de frameworks: no nos atamos a ninguna librería de software ni al soporte de los proveedores.

2.- Testeables: las reglas de negocio se pueden probar sin la interfaz de usuario, BD, servidor web u otro elemento externo.

3.- Independiente de la interfaz de usuario: podría cambiarse fácilmente.

4.- Independiente de la Base de Datos: las reglas de negocio no están vinculadas a la tecnología de Base de Datos utilizada.

5.- Independiente de cualquier agente externo: de hecho, las reglas de negocio no conocen nada sobre el mundo exterior.

Fuente: libro gratuito de Internet.

(Creo que fácil de entender)