En los úlitmos tiempos el desarrollo de software está tendiendo a la adopción y uso de arquitecturas limpias. Sobre todo en entornos empresariales, donde el mantenimiento y corrección de errores consume un valioso tiempo, y mucho dinero.
El objetivo común de todas ellas (Clean, Hexagonal, Onion,...) se puede resumir en mantener una alta cohesión, bajo acoplamiento e independencia. Lo cual aportará en conseguir un sistema testable, centrado en resolver las necesidades del dominio e independiente de UI, base de datos, frameworks, etc, etc.
En esta ocasión no voy a escribir un post hablando de las bondades (o maldades) de estas arquitecturas (hay muuuucho ya sobre el tema). Pero me gustaría compartir algunas imágenes, con las que intenté explicar la Arquitectura Hexagonal. Y dado que ya las tenía, pues las publico por aquí.
Después de mucho leer, ver imágenes y mirar código sobre Arquitectura
Hexágonal, podría afirmar que cada uno hace lo que le da la gana, lo que
entiende o lo que estima oportuno, y luego dice que aplica
"Arquitectura Hexagonal". Lo cual está bastante bien, hasta que llega el momento en que el proyecto ha crecido y nos damos cuenta de que quizá no estaba tan bien, y empezamos a decir que la arquitectura Hexagonal no cumple lo que prometía, cuando probablemente hemos sido nosotros los que hemos metido la pata.
Por delante vaya mi opinión personal que pongo resaltada:
Aplicar Hexagonal introducirá complejidad.
Piensa si merece el esfuerzo en el proyecto aplicar arquitectura Hexagonal.
¿No estás cómodo con DDD? No apliques Hexagonal.
No todos los equipos de desarrollo están preparados para adoptar esta arquitectura.
Dicho lo cual, ahí va el primer dibujo que encontrarás en cualquier sitio cuando se habla de esta arquitectura (Hexágonos concéntricos, que para eso se llama así):
Quise desglosar el dibujo anterior en el siguiente esquema, donde, yo al menos, veo mas claro cada una de las capas, artefactos y mecanismos que aplican y como se relacionan y comunican entre sí.
Por último dejo este diagrama de la propuesta para organizar el código (paquetería/directorios) que quizá me ha encajado mejor de las diversas opciones que he podido ver y probar.
Se puede apreciar que se organiza partiendo de la Entidad de dominio, para desglosar cada una de las "capas" de Hexagonal (Infraestructura, Aplicación y Dominio). Con esto se consigue una alta cohesión. Se organiza todo lo que concierne a una entidad dentro de la jerarquía de directorios o paquetes. Por supuesto existen otras maneras de organizarlo.
Con esta aproximación surgen algunas cuestiones como por ejemplo: ¿Cómo se comunican Entidades de Dominio? o ¿Cómo se pueden reutilizar validaciones/comprobaciones (especificaciones, estrategias)? ¿Cómo tratas los agregados?
Para un entorno de Microservicios esta es la organización que mas me gusta, desacoplando al máximo y usando eventos para la comunicación entre ellos (por ejemplo publicación/suscripción de mensajes).
Me guardo este artículo como chuleta, para cuando tenga que explicar/debatir nuevamente sobre este tema.
Comentarios