Robert Martin (Uncle Bob) analizó las propuestas de las arquitecturas en capas, hexagonal y screaming (Domain Driven Design), y las combinó para dar lugar a la “arquitectura limpia”.
Robert Martin, más conocido como Tío Bob (Uncle Bob en inglés), plantea que la arquitectura de un software debe gritar cuál es el uso de dicho software. Así como al ver planos de edificios, si uno ve que el edificio posee un baño, cocina, comedor, dormitorios, la arquitectura grita que es una casa familiar. De esta manera, al visualizar la arquitectura de un software, se debería notar cual es el uso del mismo. La arquitectura no debería indicar cuál es el framework o herramientas usadas para su construcción.
Volviendo al arquitecto de edificios, el mismo se asegura que un edificio cumpla con
los casos de uso antes de decidir qué materiales se usarían para su construcción. En el caso del desarrollo de software, cumplimentar esto, asegura que el producto satisfaga los casos de uso y retrase la decisión sobre los frameworks o herramientas a usar. Incluso, una buena arquitectura basada en casos de usos permite que sea fácil cambiar la herramienta que se va a usar.
CONCEPTOS PREVIOS
Arquitectura Hexagonal
La arquitectura hexagonal (también conocida como puertos y adaptadores) es una estrategia
para desacoplar los casos de uso de los detalles externos. Fue acuñado por Alistar Cockburn hace más de 13 años, y esto recibió mejoras con las arquitecturas Onion y Clean.
El objetivo de esta arquitectura es permitir que una aplicación sea dirigida por usuarios, programas o pruebas, y desarrollada y probada de forma aislada de cualquiera de sus dispositivos y bases de datos en tiempo de ejecución.
Con este estilo tenemos:
- Un dominio de negocios independiente para incorporar las reglas comerciales
detalladas. - Casos de uso que interactúan con el dominio e independientes de los servicios externos. - Interfaces que proporcionan puertos. - Adaptadores que proporcionan implementaciones de marcos, acceso a datos y UI. - Externamente el usuario, otros sistemas y servicios. Una forma de explicar la arquitectura hexagonal es por sus formas. Echa un vistazo a la siguiente imagen:
- La forma de patata azul en el centro es la capa de dominio y hay razones para ello. Cada dominio de negocios tiene sus propias reglas, reglas de negocios muy específicas, que es la razón de su forma indefinida. Por ejemplo, diseñé nuestra capa de dominio con bloques de construcción DDD. - La aplicación tiene una forma hexagonal porque cada uno de sus lados tiene protocolos específicos. - Los puertos y adaptadores se implementan fuera de la aplicación como complementos. - Externamente tenemos otros sistemas.
El hexagonal se divide en izquierda y derecha. A la izquierda implementamos los actores
impulsores y a la derecha implementamos los actores secundarios.
La dirección de las dependencias va hacia el centro, por lo que la capa de dominio no conoce la capa de aplicación, pero la capa de aplicación depende del dominio, la misma regla se aplica a las capas externas.
Reglas de negocio y casos de uso
Las reglas de negocio son las reglas detalladas, que encapsulan los campos y restricciones de la entidad. También las reglas de negocios son los casos de uso que interactúan con múltiples entidades y servicios. Juntos crean un proceso en la aplicación, deben mantenerse durante mucho tiempo.
Las reglas de negocio ganarían o ahorrarían dinero a la empresa, independientemente de si se
implementan en una computadora. Ganarían o ahorrarían dinero incluso si fueran ejecutados manualmente. En la era DDD, tenemos patrones para describir las reglas de negocios con Entidades, Objetos de Valor, Agregados, Servicios de Dominio, etc. Son una combinación perfecta con la arquitectura hexagonal.
Las reglas de negocios y los casos de uso deben implementarse dentro de la capa de aplicación y deben mantenerse durante la vida del proyecto. Por otra parte, todo lo que da soporte para capacidades externas son solo detalles externos, pueden ser reemplazados por diferentes razones, y no queremos que las reglas de negocio se acoplen a ellas.
Detalles externos
En la mayoría de los escenarios, podemos aplazar la implementación de detalles externos y
seguir manteniendo el progreso del desarrollo. Si su respuesta es afirmativa para cualquiera de las siguientes preguntas, probablemente esté tratando con detalles periféricos:
- ¿La aplicación necesita una base de datos para persistir el estado?
- ¿La aplicación requiere una interfaz de usuario? - ¿La aplicación consume una API externa?
Estos son detalles externos comunes que pueden ser burlados, falsificados o que su implementación concreta puede ser reemplazada por diferentes motivos. Le sugiero que aplace su implementación mientras descubre más del dominio. Tenga en cuenta la cita del tío Bob:
“Una buena arquitectura permite aplazar decisiones importantes y un buen arquitecto
maximiza la cantidad de decisiones que no se toman.”
Visual Studio facilita la adición de bibliotecas para Reflexión, Serialización, Seguridad y muchos otros paquetes Nuget en nuestros proyectos. El problema comienza cuando agregamos estas bibliotecas a nuestra aplicación y dominio. Estas bibliotecas son solo detalles y deben quedar fuera de la capa de aplicación.
¿Qué deberíamos hacer?
Deja de ir por los marcos brillantes.
Deja de escribir clases con herencia de los marcos.
Concéntrese en las reglas de negocios, aclárelas en sus capas de aplicación y dominio.
No caiga en trampas de herramientas como los scaffolding.
Crear la abstracción adecuada para estas preocupaciones periféricas.
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 adentro.
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.
ARQUITECTURA LIMPIA
Todas las arquitecturas tienen el mismo objetivo común, que es la “separación de intereses”, para dar como resultado sistemas que son:
Independientes de frameworks: no nos atamos a ninguna librería de software ni al
soporte de los proveedores. Testeables: las reglas de negocio se pueden probar sin la interfaz de usuario, BD, servidor web u otro elemento externo. Independiente de la interfaz de usuario: podría cambiarse fácilmente Independiente de la BD: las reglas de negocio no están vinculadas a la tecnología de BD utilizada Independiente de cualquier agente externo: de hecho, las reglas de negocio no conocen nada sobre el mundo exterior. La regla de la dependencia Los círculos concéntricos representan diferentes áreas del software. En general, cuanto más alejados, más alto será el nivel del software. Los círculos exteriores son mecanismos. Los círculos internos son políticas.
La regla principal que hace que esta arquitectura funcione es la regla de dependencia. Esta regla dice que las dependencias del código fuente solo pueden apuntar hacia adentro. Nada en un círculo interno puede saber nada acerca de algo en un círculo exterior. En particular, el nombre de algo declarado en un círculo exterior no debe ser mencionado por el código en el círculo interno. Eso incluye, funciones, clases, variables, o cualquier otra entidad de software nombrada.
De la misma manera, los formatos de datos utilizados en un círculo exterior no deben ser utilizados por un círculo interno, especialmente si esos formatos son generados por un framework en un círculo externo. No queremos que nada en un círculo exterior afecte los círculos internos.
Entidades Las entidades encapsulan las reglas de negocio de toda la empresa. Una entidad puede ser un objeto con métodos, o puede ser un conjunto de funciones y estructuras de datos. No importa, siempre y cuando las entidades puedan ser utilizadas por muchas aplicaciones diferentes en la empresa.
Si no tiene una empresa y solo está escribiendo una aplicación, estas entidades son los objetos comerciales de la aplicación. Encapsulan las reglas más generales y de alto nivel. Es menos probable que cambien cuando algo externo cambia. Por ejemplo, no esperaría que estos objetos se vieran afectados por un cambio en la navegación de la página o por la seguridad. Ningún cambio operacional en ninguna aplicación en particular debe afectar la capa de la entidad.
Casos de uso El software en esta capa contiene reglas de negocio específicas de la aplicación. Encapsula e implementa todos los casos de uso del sistema. Estos casos de uso orquestan el flujo de datos hacia y desde las entidades, y dirigen a esas entidades a utilizar sus reglas de negocios en toda la empresa para lograr los objetivos del caso de uso.
No esperamos que los cambios en esta capa afecten a las entidades. Tampoco esperamos que esta capa se vea afectada por cambios en las externalidades, como la base de datos, la interfaz de usuario o cualquiera de los marcos comunes. Esta capa está aislada de tales preocupaciones. Sin embargo, esperamos que los cambios en el funcionamiento de la aplicación sí afecten a los casos de uso y, por lo tanto, el software en esta capa. Si los detalles de un caso de uso cambian, entonces algunos códigos en esta capa ciertamente se verán afectados.
Adaptadores de interfaz El software en esta capa es un conjunto de adaptadores que convierten los datos desde el formato más conveniente para los casos de uso y las entidades, al formato más conveniente para algún agente externo, como la BD o la Web. Es esta capa, por ejemplo, la que contendrá por completo la arquitectura MVC de una GUI. Los presentadores, vistas y controladores pertenecen todos a esta capa. Es probable que los modelos sean sólo estructuras de datos que pasan de los controladores a los casos de uso y luego regresan de los casos de uso a los presentadores y las vistas.
De manera similar, los datos se convierten, en esta capa, desde la forma más conveniente para las entidades y los casos de uso, a la forma más conveniente para cualquier estructura de persistencia que se esté utilizando, es decir, la base de datos. Ningún código hacia el interior de este círculo debe saber nada sobre la base de datos. Si la base de datos es una base de datos SQL, entonces todo el SQL debe estar restringido a esta capa, y en particular a las partes de esta capa que tienen que ver con la base de datos.
También en esta capa se encuentra cualquier otro adaptador necesario para convertir datos de algún formulario externo, como un servicio externo, al formulario interno utilizado por los casos de uso y las entidades.
Frameworks (marcos) y Drivers (controladores).
La capa más externa generalmente se compone de marcos y herramientas como la Base de datos, el Marco web, 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 debes 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.
Usualmente 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 nombre 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.
Qué datos cruzan los límites.
Normalmente, los datos que cruzan los límites son estructuras de datos simples. Puede usar estructuras básicas o simples objetos de transferencia de datos si lo desea. O los datos pueden ser simplemente argumentos en llamadas a funciones. O puede empaquetarlo en un mapa hash, o construirlo en un objeto. Lo importante es que las estructuras de datos aisladas y simples se pasan a través de los límites. No queremos engañar y pasar Entidades o filas de bases de datos. No queremos que las estructuras de datos tengan ningún tipo de dependencia que infrinja la Regla de dependencia.
Por ejemplo, muchos frameworks de bases de datos devuelven un formato de datos
conveniente en respuesta a una consulta. Podríamos llamar a esto una Estructura de Fila. No queremos pasar esa estructura de fila hacia el interior a través de un límite. Eso violaría la Regla de dependencia porque obligaría a un círculo interno a saber algo sobre un círculo exterior.
Entonces, cuando pasamos datos a través de un límite, siempre será en la forma más conveniente para el círculo interior.
Conclusión Cumplir con estas reglas simples no es difícil, y le ahorrará muchos dolores de cabeza en el futuro. Al separar el software en capas y cumplir con la Regla de dependencia, creará un sistema que es intrínsecamente comprobable, con todos los beneficios que esto implica. Cuando cualquiera de las partes externas del sistema se vuelven obsoletas, como la base de datos o el marco web, puede reemplazar esos elementos obsoletos con un mínimo de esfuerzo.
POSIBLES IMPLEMENTACIONES
CAPA APPLICATION
Vamos a profundizar en las Reglas de Negocios de Aplicación implementadas por los Casos de Uso en nuestro Contexto Limitado. Como dijo el tío Bob en su libro Arquitectura limpia:
“Del mismo modo que los planes para una casa o una biblioteca gritan sobre los casos de uso de esos edificios, también lo debe hacer la arquitectura de una aplicación de software sobre los casos de uso de la aplicación.”
Las implementaciones de casos de uso son módulos de primera clase en la raíz de esta capa. La forma de un Caso de Uso es un objeto Interactor que recibe una Entrada, haga un trabajo y luego pase la Salida a través de la persona que llama. Esa es la razón por la que soy un defensor de las carpetas de características que describen los casos de uso y dentro de ellas las clases necesarias: Con un primer vistazo de las carpetas de soluciones, se puede crear una idea del propósito de este software. Parece que puede administrar su cuenta de banco, por ejemplo, puede depositar o retirar dinero. A continuación vemos la comunicación entre las capas:
La aplicación expone una interfaz (puerto) a la capa UI y otra interfaz (otro puerto) a la capa de infraestructura. Lo que ha visto hasta aquí es que Enterprise + Application Business Rules se aplica sin dependencias de marcos o sin acoplamiento de base de datos. Todos los detalles tienen abstracciones que protegen las Reglas de Negocios que deben ser acopladas a cosas tecnológicas.
CAPA UI (Adaptadores para la interfaz de usuario)
Ahora avanzamos a la siguiente capa, en la Capa de Interfaz de Usuario traducimos la entrada
de manera que los Casos de Uso puedan entender, es una buena práctica no reutilizar las entidades en esta capa porque podría crear un acoplamiento, el front-end tiene marcos específicos, otras formas de crear sus estructuras de datos, presentación diferente para cada campo y reglas de validación.
En nuestra implementación tenemos las siguientes carpetas de características para cada caso de uso: - Request: una estructura de datos para la entrada del usuario (accountId y monto). - Un controlador con una acción: este componente recibe el DepositRequest, llama al caso de uso de depósito apropiado, el cual realiza un procesamiento y luego pasa la salida a través de la instancia de Presenter. - Presentador: convierte la salida al modelo. - Modelo: esta es la estructura de datos de retorno para aplicaciones MVC.
Debemos resaltar que el Controlador conoce el Caso de uso de depósito y
no está interesado en la Salida, en lugar de eso, el Controlador delega la responsabilidad de generar un Modelo para la instancia del Presentador.
CAPA INFRAESTRUCTURE (Adaptadores para la infraestructura)
Otra capa externa es la capa de infraestructura que implementa acceso a datos, marco de inyección de dependencias (DI) y otras especificaciones de marcos. En este ejemplo tenemos múltiples implementaciones de acceso a datos.
How and When the DI is configured
Agrupamos la DI por módulos, por lo que tenemos un módulo para el acceso a datos de Entity Framework que requiere una cadena de conexión como esta: public class Module : Autofac.Module { public string ConnectionString { get; set; }
{ var optionsBuilder = new DbContextOptionsBuilder<DbContext>(); optionsBuilder.UseSqlServer(ConnectionString); optionsBuilder.EnableSensitiveDataLogging(true);
