Presentamos los cursos de CodelyTV: ¡CodelyTV Pro! 🚀

¡Subscríbete ahora y aprovecha la oferta de lanzamiento al 50%!

Introducción Arquitectura Hexagonal – DDD

Hoy sentaremos los principios sobre la Arquitectura de Software y, más en concerto, sobre qué es la Arquitectura Hexagonal. Tras una primera temporada donde hemos hablado al respecto de los principios SOLID, y hemos visto los problemas del código acoplado en términos de testabilidad, vamos a pasar a dar un salto en cuanto al diseño de Software y nos centraremos en la Arquitectura de Software, o como lo denominaba Sandro Mancuso: “Macro-design”.

Arquitectura de Software

Complejidad accidental vs. complejidad esencial
Complejidad accidental vs. complejidad esencial

En este vídeo hablaremos sobre la Arquitectura Hexagonal, pero antes, introduciremos el concepto de Arquitectura de Software y justificaremos en qué contexto sería necesario plantear una estrategia a seguir al respecto. Nos apoyaremos en el concepto de Complejidad Accidental vs. Complejidad Esencial para justificar la necesidad de plantear unas reglas de juego a la hora de diseñar Software que nos permitan mantener la Complejidad Accidental a raya.

Clean Architecture

Clean Architecture
Clean Architecture

Después de introducir el concepto de Arquitectura de Software, hablaremos de las “arquitecturas limpias” (😅) o Clean Architecture. Éstas son un tipo de arquitectura que, como plantea Uncle Bob, establecen una serie de delimitaciones en cuanto a las capas de nuestra aplicación, y proponen una regla de dependencia entre ellas que va de fuera hacia dentro. De esta forma, conseguimos evitar el acoplamiento de nuestro dominio con elementos más externos, hecho que nos permitirá una alta tolerancia al cambio.

Es interesante explorar este concepto y ver que es algo completamente agnóstico al tipo de aplicaciones. Si bien es cierto que dependiendo de si estamos haciendo una aplicación móvil o una API REST, tendremos que tener en cuenta ciertos aspectos concretos de nuestro contexto, en un nivel de abstracción como el que se plantea cuando hablamos de Clean Architecture, podemos encontrar grandes puntos en común. Tanto es así que aquí podéis ver un ejemplo de aplicación de Clean Architecture en Android, en iOS, o en PHP.

Layers architecture

Layers architecture
Layers architecture

Antes de entrar en materia al respecto de la Arquitectura Hexagonal, cabe destacar la diferencia con la arquitectura en capas o “Layers architecture”. Tal y como podemos ver en la imagen anterior, la arquitectura en capas tendría como centro la base de datos. Es decir, el dominio sería conocedor del sistema de persistencia y, por tanto, estaría acoplado a éste. Éste patrón lo vemos inevitablemente cuando hablamos de aplicaciones basadas en Active Record. Podemos encontrar este tipo de aplicaciones de forma bastante extendida en el mundo Ruby on Rails ya que, por defecto, es lo que nos propone este framework.

Arquitectura hexagonal
Arquitectura hexagonal

Por contra, en la Arquitectura Hexagonal (también llamada Ports and Adapters), tal y como podemos ver en la imagen anterior, la base de datos se concibe como uno más de los puertos con los que nuestro dominio interactúa. No obstante, para llevar a cabo esta interacción, siempre estaríamos aplicando el Principio de Inversión de Dependencias de tal forma que no nos acoplaríamos a la implementación en concreto del cliente de base de datos, si no a una interface (contrato) que sí residiría dentro de nuestro dominio.

Arquitectura Hexagonal

Hexagonal Architecture
Hexagonal Architecture

¿Por qué Hexagonal?

Sinceramente, prefiero el nombre alternativo “Ports and adapters” o “Puertos y adaptadores”.

  • No induce a error al pensar en posibles limitaciones de 6 capas (por lo del hexágono).
  • Incorpora el concepto de “puerto” a nivel teórico, extrapolable fácilmente al concepto de interface a nivel de implementación.
  • Añade el concepto de “adapter”, patrón de diseño usado ampliamente al aplicar el DIP.

¿Qué tiene que ver con el Domain-Driven Design (DDD)?

Al ser una arquitectura que fomenta el que nuestro dominio sea el núcleo de todas las capas, y que no se acople a nada externo, encaja muy bien con la idea del DDD. Al fin y al cabo, la parte táctica del Domain-Driven Design no es más que la agrupación de muchos conceptos y patrones de diseño ya existentes. Así entonces, podríamos decir que el DDD se basa en la Arquitectura Hexagonal como pilar central en términos de arquitectura.

¿Qué beneficios tiene?

Principalmente y fundamentado en el hecho del desacoplamiento, tenemos beneficios directamente en forma de:

A su vez, también cabe destacar el hecho de que, al estar basada en los contratos establecidos por los puertos que definamos, nos permite postponer decisiones a nivel de implementación (qué adaptador implementaremos para ese puerto). Esto facilita el desarrollo dirigido por test (TDD) ya que nos podemos centrar en la clase que estamos desarrollando sin necesidad de implementar sus colaboradores en ese estricto momento. Os recomiendo el post de Eduardo Ferro al respecto: El arte del patadon pa’lante / Postponer decisiones técnicas.

 

Sin más, aquí el vídeo:

En futuros vídeos iremos desgranando cada una de las capas de esta arquitectura y entraremos más en materia a través de ejemplos de código. Así entonces, si ya os surgen dudas, plantearlas sin problema en los comentarios de este vídeo y así las podremos atacar en los siguientes :D.

Por último, también os dejo el enlace al post que comento en el vídeo de Fideloper, un buen recurso para empezar a trastear con este tema 🙂

SHOWHIDE Comments (6)
  1. ¡Wow! ¡Menuda introducción!

    Me parece un vídeo super trabajado: muchas referencias, material visual muy cuidado,… Muchas gracias por poner tanto esfuerzo en él.

    Además, me he quedado con muchas, muchas ganas de ver el siguiente. Esta arquitectura me parece muy interesante, difícil de implementar a rajatabla (cada proyecto tiene sus particularidades). A veces da la impresión de sobredimensionar la solución, de ahí que sea difícil también de vender a jefes y compañeros.

    Lo dicho, deseando ver los siguientes vídeos, y muchas gracias por todo el trabajo.

  2. Me ha parecido muy interesante, es un tema en el que llevo detrás de el mucho tiempo y nunca he sabido bien bien como abordarlo.

    Tengo pensado comprarme los dos libros, el azul y el rojo, junto con el de Carlos Buenosvinos, pero la verdad es que material visual y videos explicativos van geniales!

    Con ganas de ver el siguiente 🙂

  3. Fantástico video! Lanzo una duda que suelo tener, por si quieres abordarla próximamente en algún video:

    Cuando quiero hacer una validación de parámetros (que un usuario ha introducido en un formulario por ejemplo), donde tiene más sentido hacer esta validación: a) En el controlador para pasar los parámetros ya limpios al caso de uso? b) En el propio caso de uso para reutilizar el código? c) en otro sitio?

    Merci!

Leave a Reply

Your email address will not be published.

¡Presentamos #CodelyTvPro! 🚀

¡Subscríbete ahora y aprovecha la oferta de lanzamiento al 50%!