Arquitectura

hexagonal en Drupal
Cómo construir un producto usando DDD y con
Drupal como infraestructura

Carlos Escuriola Marín

Thanks to our Platinum Sponsors!!
Thanks to our Gold, Silver and
Bronze Sponsors!!
 La ley de los dos pies

Si en algún momento sientes que no estás aprendiendo o

contribuyendo en nada, usa tus dos pies. Vete a otra sala
donde puedas aprender o contribuir.

Nadie debería estar en una charla que no le está aportando

 Objetivos

● Por qué DDD me resultó útil para mi proyecto

● Cómo hacer DDD en Drupal
 Encuesta

¿Cuántos habéis trabajado con DDD?

¿Alguien ha trabajado con DDD en Drupal?

 ¿Por qué DDD? Mi historia

● En 2013 trabajando en una startup hicimos un piloto para un producto

para la gestión de procesos de selección en Drupal 7
● El producto - Talent Clue - fue creciendo mucho (actualmente sigue
vivo y tiene +1M de nodos) y consiguió muchos clientes
● Durante muchos años fuimos añadiendo al “piloto” funcionalidad
(lógica de negocio) en los módulos de Drupal de forma ASM
● Las reglas de negocio estaban muy drupalizadas
● No tenía tests, ni hicimos refactors… y pasaron años y años…
 ¿Por qué DDD? Mi historia
Problemas:
- Equipo muy potente en Drupal pero el producto se nos iba de las manos
- Mucho código legacy, dificultad para añadir nuevas funcionalidades
- Teníamos problemas de performance
- Al no haber tests era habitual romper cosas al subir
- No fuimos capaces de migrar a Drupal 8
- Nos era complicado contratar developers
 ¿Por qué DDD? Mi historia

Contratamos consultores expertos en rescatar código legacy

- Empezamos añadiendo tests que nos dieran confianza (TDD)
- Luego refactors e introducimos OO
- Se hicieron muchas reuniones para acotar/definir el “dominio”
- Como conclusión, nos instaron a hacer DDD ¡dentro de Drupal!
 ¿Por qué DDD? Mi historia

Mejoró la cosa:
- Empezamos lento pero acabamos cogiendo mucha velocidad
- Todo lo que hacíamos tenía sus tests
- Empezamos a ser decoupled usando Angular que consumía los
servicios que creamos
- Contratamos developers

Seguramente sin este proceso no habríamos podido avanzar tan rápido

 ¿Por qué DDD? Mi historia
Pura fantasía, pero la realidad es que me costó aceptarlo.
Este era yo:

Al final lo entendí y por eso estoy hoy aquí

 Llegados a este punto…

- Debe ser una decisión consensuada del

equipo
- “A lo drupal” a veces es la opción correcta
- Drupal mola, pero a veces hay que
plantearse alternativas
 Pero… ¿qué es DDD?

¿Y Dominio? ¿Y arquitectura de Software? ¿Y arquitectura hexagonal?

¿Y bounded context? ¿Y Entity? ¿Y ValueObject? ¿Y Evento de dominio?
¿Y lenguaje ubicuo? ¿Y agregados? ¿Y Domain expert? …

Me preocupaba por saber Drupal pero no investigué si se podían hacer las cosas de
otra forma
 Introducción Arquitectura de Software y DDD

➔ Arquitectura de Software

◆ Arquitecturas limpias

● Arquitectura Hexagonal

➔ DDD
 Arquitectura de Software

Conjunto de reglas y patrones que proporcionan un marco de referencia permitiendo al equipo

compartir una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación

Desarrollar “a lo Drupal” también tiene su arquitectura de Software, pero…

 Arquitectura de Software

Problemas típicos cuando usamos Drupal u otro

framework son:

- “Drupalización” de la lógica del negocio

- Acoplamiento con la infraestructura

Consecuencias:

- Dificulta el testing (sobretodo testing unitario).

- Impide el cambio a otro sistema.
- Dificulta el crecimiento/mantenimiento.
 Arquitecturas limpias

Arquitecturas que nos permitan separar las responsabilidades

mediante capas y definiendo reglas de dependencias entre
ellas. Esto evitará el acoplamiento de nuestro dominio con
elementos externos lo que producirá sistemas:

- Independientes del framework, de la UI, de la BD, de agentes

externos.
- Testables.
- Más tolerantes al cambio.
- Reutilizables.
- Mantenibles.
 Arquitectura Hexagonal (Ports & Adapters)

Alistair Cockburn

Mejor llamarla “Ports & Adapters”

Separación por capas con responsabilidad:

- Dominio
- Aplicación
- Infraestructura
 Arquitectura Hexagonal (Ports & Adapters)

Dominio

- Núcleo de las capas sin acople a nada externo

- Contiene las reglas de negocio. En ella podemos encontrar los
modelos de datos y sus restricciones.
Esta capa no conoce cómo se estructurará, se guardará y se recuperará la información del
repositorio. Simplemente expondrá una serie de interfaces (puertos) que serán adaptados en la
capa de infraestructura para cada caso concreto de implementación de esa persistencia.
 Arquitectura Hexagonal (Ports & Adapters)

Aplicación

- Donde se definen los distintos casos de uso.

- Se hace pensando en las interfaces disponibles y no en las
tecnologías
En esta capa también se adaptan las distintas peticiones que recibe la aplicación a través
desde la capa de infraestructura. Por ejemplo, un caso de uso aceptará los datos de entrada
que provienen de la capa de infraestructura y realizará las acciones necesarias para devolverle
unos datos de salida.
 Arquitectura Hexagonal (Ports & Adapters)

Infraestructura

- Implementaciones o adaptaciones de las interfaces o puertos de las

demás capas.
- Framework (Drupal) + librerías de terceros + SDKs… cualquier otro
código externo a la aplicación.
Implementa los servicios definidos en la capa de aplicación (adaptadores secundarios). Por ejemplo, si
tenemos definido un servicio para enviar email, en esta capa implementaremos el servicio de acuerdo a
los requisitos del proveedor o cualquier librería externa.

Contiene lo relativo a la interacción con el usuario (adaptadores primarios). Obtendrá unos datos de
entrada que serán utilizados para solicitar el caso de uso correspondiente en la aplicación y devolverá
unos datos de salida. Podemos encontrar los controladores HTTP o scripts de línea de comandos, entre
otros.
 Domain Driven Design - Términos clave

- Lenguaje ubicuo
- →“DDD es, ante todo, una conversación”
- Lógica de dominio/negocio
- Patrones de diseño
- Bounded context
- Entidades / Agregados
- ValueObjects
 Domain Driven Design - Inconvenientes

- Require extenso conocimiento del dominio

- Si el dominio no es complejo no vale la pena
- Puede ser más costoso de tiempo
 Cómo crear un proyecto DDD en Drupal

Ejemplo de un caso de uso: From Domain to Drupal

● Definición del dominio
● Ejemplo práctico
 Caso Irreal

- Horse Luis: Estaba pensando…

- Maricarmen: ¿En qué piensas Horse Luis?
- HL: Llevo un tiempo planteándomelo
- MC: ¿El qué te planteas Horse Luis?
- HL: No me gusta rellenar un Google Forms
para enviar un paper
- MC: A nadie le gusta Horse Luis
- HL: Quiero entrar en la organización de la
DrupalCamp y hacer la web del Call for
papers
- MC: Anda y tómate un choleck Horse Luis

https://ideogram.ai/g/NM2K4Ld2TjS0dYbay9sZLQ/3
 Ejemplo de un caso de uso: From Domain to Drupal
Ayudemos a Horse Luis a hacer la web Call for papers de la Drupalcamp
→ Horse Luis se ha reunido con los Expertos de Dominio y han definido el
Dominio y sus reglas de negocio

Paper submission: El paper Por cada

Por cada
Un speaker puede puede ser de paper no
paper
subir uno o más tipo charla o seleccionado
seleccionado
Por cada
papers junto con taller se enviará un
como backup
paper
sus datos y su mail al autor
- Una sala tiene nombre, edificio se enviará un
seleccionado
biografía mailsealenviará
autor un
en el que está, dirección y planta.
- Se pueden crear salas mail al autor
- La sala tiene nombres vetadosSe generará un
Se asignará calendario con los
Un usuario con Los papers pueden
una sala y un papers seleccionados
rol organizador ser seleccionados,
intervalo de en las salas
puede dar no seleccionados o
tiempo para asignadas en el
feedback de un backup
cada paper intervalo
paper
seleccionado correspondiente
 Cómo crear un proyecto DDD en Drupal

From Domain to Drupal

● Crear bounded context drupalcamp y estructura de directorios
para la separación de las capas
● Implementar la Entidad de la sala, el Repositorio (y sus tests)
● Implementación Caso de uso de crear sala (y sus tests)
● Crear content type en Drupal
● Services, Routing y Controllers
● Hacer las peticiones en la parte Drupal de la infraestructura
 Ejemplo de un caso de uso: From Domain to Drupal
Ayudemos a Horse Luis a hacer la web Call for papers de la Drupalcamp
→ Horse Luis se ha reunido con los Expertos de Dominio y han definido el
Dominio y sus reglas de negocio

Paper submission: El paper Por cada

Por cada
Un speaker puede puede ser de paper no
paper
subir
- uno
Unao más tipo charla
sala tiene nombre, o
edificio, seleccionado
seleccionado
Por cada
papers dirección
junto con y planta. taller se enviará un
como backup
paper
sus- datos y su
Se pueden crear salas mail al autor
se enviará un
seleccionado
biografía
- La sala tiene nombres vetados mailsealenviará
autor un
mail al autor
Nueva petición: Se generará un
Se asignará - El nombre de la sala se puede calendario con los
Los papers pueden
Un usuario con cambiar
una sala y un papers seleccionados
rol organizador sertiene
- La sala seleccionados,
también un código en las salas
intervalo de puede dar no seleccionados o
tiempo para interno asignadas en el
feedback de un backup
cada paper intervalo
paper
seleccionado correspondiente
 ¿Por qué DDD?

Aprendizaje
- Me preocupaba por saber Drupal pero no investigué si se podían
hacer las cosas de otra forma
- Si el proyecto es complejo y tiene mucha lógica de negocio,
arquitectura hexagonal / DDD realmente te puede salvar la vida
- Que todo esto se puede usar con Drupal
 ¿Por qué DDD?

Lo que más me gusta

- Que todos usamos el mismo lenguaje - lenguaje ubicuo

- Negocio y developers más alineados
- Dominio (reglas de negocio) protegidas
- Código más abierto a otros developers
- Ideal para complementar con Front desacoplado
 Para saber más

- Codium Team
- Codely
- Links
- Carlos buenosvinos (Canal Youtube / Libro)
- Fran Iglesias
- Desacoplar la lógica de negocio del framework
Thanks to our Platinum Sponsors!!
Thanks to our Gold, Silver and
Bronze Sponsors!!
Preguntas…