Aplicando el patrón Clear Architecture a un microservicio
Session 4: 2h39m
Antecedentes
En los últimos años hemos visto una amplia gama de ideas con respecto a la arquitectura de los sistemas. Estos incluyen:
- Hexagonal Architecture (a.k.a. Ports and Adapters) por Alistair Cockburn y adoptado por Steve Freeman y Nat Pryce en su libro Growing Object Oriented Software.
- Arquitectura de cebolla por Jeffrey Palermo.
- Screaming Architecture de un blog de Robert C. Martin
- DCI de James Coplien y Trygve Reenskaug.
- BCE por Ivar Jacobson de su libro Object Oriented Software Engineering: A Use-Case Driven Approach.
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Arquitectura Hexagonal
- La arquitectura hexagonal, también conocida como patrón de puertos y adaptadores intentan mantener toda la lógica y los modelos de negocios en un solo lugar y todo los demás depende de esto en lugar de lo contrario.
- Si miramos desde cualquier perspectiva de capas de aplicación, las dependencias serían hacia el dominio desde el controlador/interfaz y la persistencia en lugar de la arquitectura en capas que solemos hacer en nuestros proyectos. De esta manera hacemos que estos hexágonos sean independientes y puedan relacionarse con el contexto acotado en términos DDD. Al usar la analogía anterior, arquitectura se llamaría "Plugin-Architecture"; Su modelo base permanece intacto y puede ampliar aún más las funcionalidades colocando más implementaciones de plugin que se adhieran a las mismas interfaces.
Objetivo de Clean Architecture
El objetivo principal de Clean Architecture es permitir que el negocio se adapte a la tecnología e interfaces cambiantes. Si bien Internet puede pasar del escritorio al móvil, o del móvil al asistente virtual, el negocio principal sigue siendo el mismo. Particularmente en el acelerado mundo de los marcos de Javascript y las bibliotecas front-end, el uso de una arquitectura limpia puede salvarlo del patrón común de acoplar estrechamente la lógica empresarial a la capa de presentación o al marco.
Características de Clean Architecture
- Se trata de la separación de responsabilidades. Dividir el software en capas.
- Debe ser independiente de los Framworks
- Debe ser testeable
- Debe ser independiente de la interfaz de usuario
- Debe ser independiente de la base de datos
- Debe ser independiente de las dependencias de erd party
- Avanzando hacia adentro, el nivel de abstracción y el aumento de políticas.
- El círculo más interno es el más general/nivel más alto
- Los círculos internos son políticas
- Los círculos exteriores son mecanismos
- Los círculos internos no pueden depender de los círculos externos
- Los círculos exteriores no pueden influir en los círculos internos.
Componentes de Clean Architecture
Entidades
- Las entidades deben ser utilizables por muchas aplicaciones (reglas de negocio críticas) y no deben verse afectadas por nada más que un cambio en la regla de negocio crítica en sí.
- Encapsulan las reglas más generales/de alto nivel.
Casos de uso
- Los casos de uso son reglas de negocio específicas de la aplicación.
- Los cambios no deben afectar a las Entidades
- Los cambios no deben verse afectados por la infraestructura, como una base de datos.
- Los casos de uso orquestan el flujo de datos que entran/salen de las entidades y dirigen a las entidades a usar sus reglas de negocio críticias para lograr el caso de uso.
Adaptadores de interfaz
- Convierten datos de capas de datos en capas de casos de uso o capas de entidad. Los presentadores, las vistas y los controladores pertenecen aquí.
- Ningún código más avanzado en (casos de uso, entidades) debe tener ningún conocimiento de la base de datos.
Frameworks & Drivers
- Estos son el pegamento que engancha las diversas capas hacia arriba.
- Los detalles de la infraestructura viven aquí.
- No estás escribiendo mucho de código, es decir, usamos SQL Server, perno lo escribimos.
Interacción de Clean Architecture
Cruzando límites
- El flujo de control pasó del controlador, a través del caso de uso de la aplicación, luego al presentador.
- Las dependencias del código fuente apuntan hacia los casos de uso.
- Principio de inversión de dependencias
- El caso de uso necesita llamar a un presentador, hacerlo violaría la regla de dependencia: los círulos internos no pueden llamar (o conocer) círculos externos.
- El caso de uso necesitaría llamar a una interfaz
- La implementación de esta interfaz sería proporcionada por la capa de adaptador de interfaz: así es como se invierte la dependencia.
- Este mismo tipo de inversión de control se utiliza en toda la arquitectura para invertir el flujo de control.
Datos cruzando fronteras
- Normalmente, los datos que cruzan los límites consisten en estructuras de datos simples.
- No pase objetos de entidad ni filas de datos. Esto violaría las reglas de dependencia.
- Los datos se pasan en el formato que sea más conveniente para el círculo/capa interna.
- Estas son estructuras de datos aisladas y simples.
- Lo que significa que nuestros DTO necesarios para cruzar los límites deben pertenecer al círculo interno, o al menos a su definición (interfaz, clase abstracta).
Ejemplo de código
Comments
Post a Comment