Featured image of post Mejorando el "Command use case" con el "Domain event"

Mejorando el "Command use case" con el "Domain event"

Por fin llega el complemento que necesitamos para notificar cambios en el dominio tanto dentro como fuera de nuestro 'Bounded context', la carta 'Domain event'

Abriendo debate técnico

1
TODO: Enlazar con el Read model

Agregando funcionalidad olvidada en el caso de uso básico. Los Domain event

Si nos fijamos en las características de la carta Territory-Domain model y Primary-Aggregate root, veremos que básicamente dicen que “si cambia el estado de una entidad, se produce o nace un evento de dominio”.

Pues nada, buscamos la carta Flow-Domain event y la colocamos en su lugar, después de Aggregate root. Se considera una carta de flujo porque va paralela al flujo normal y afecta a otras áreas fuera del caso de uso.

Add domain event

Aunque parezca que ya está hecho el trabajo poniendo esta carta, nos falta un poco de recorrido. Lo veremos a continuación.

¿A dónde van y para qué sirven los domain events?

Seguramente os habréis dado cuenta que las cartas que contienen información acaban siempre en algún lugar y desaparecen cuando alguna carta le da un uso. Los Commands y Querys acaban su ciclo en los Use case, los Aggregate root y sus hijos acaban usándose en Persistence y Response. Entonces el Domain event… ¿dónde va?, ¿quién lo usa?…

Pues el Domain event ahí donde lo veis, es la pieza de información más importante, ya que se usa para cohesionar tanto los Modules de un mismo Bounded context, como los Bounded contexts entre ellos. Eso sí, tiene reglas muy concretas que se deben cumplir a raja tabla para no enviar información falsa al exterior. Sus características y estrategias para usarlo pueden cubrir un libro. Aquí sólo hablaremos por encima en el capítulo que habla sobre esta carta.

De la misma forma que explicamos el Command / Query bus en el caso de uso de tipo Command, procederemos a explicar el Event bus. Colocamos la carta Ability - Event bus en la tercera fila y la de Implementation- Event bus En la cuarta fila.

De momento, nos quedaría algo como esto:

Add domain event

Esto nos asegura que el Domain event tiene una salida a un Bus. Luego dependerá de nosotros el uso que le queramos dar a dicho mensaje.

Publicando el Domain event del Event bus a un Queue

Pero todavía hay algo más. Los mensajes van a un Bus, pero en realidad queremos que acabe almacenado en una cola o Queue. Necesitamos decirle a Symfony messenger qué tecnología usaremos para implementar la cola donde se guardará el Domain event. El Command/Query bus acababa en el Use case y Symfony messenger era autosuficiente, ya que el mensaje se movía dentro de sus fronteras, pero el Event bus acaba en una Queue, fuera de nuestras fronteras. Dependiendo de lo que queramos conseguir, usaremos una tecnología u otra, con lo que hay que especificar la tecnología de soporte que lo va a almacenar para los interesados. En este caso decidimos usar Bus-RabbitMQ, pero podríamos haber escogido Bus-AmazonSNS o Bus-Kafka

Add domain event

Una vez hemos publicado el Domain event en el bus, podemos hacer que un sinfín de Consumers escuchen este evento y reaccionen a él.

La foto final sería algo similar a esto:

Add domain event

Ya tenemos los eventos disponibles para ser consumidos por terceros. Ahora nos hace falta escuchar los eventos para alimentar el Read model del que hablábamos en el post Optimizando el caso de uso “Query”. Lo veremos en uno de los ejemplos de Console command.

Licensed under CC BY-NC-SA 4.0
Creado con Hugo
Tema Stack diseñado por Jimmy