CQRS y notificación por correo electrónico

Question

Leyendo sobre CQRS se habla mucho de notificaciones por correo electrónico, me pregunto de dónde obtener los datos. Imagine un senario donde un usuario invita a otros usuarios a un evento. Para informar a un usuario que ha sido invitado a un evento, se le envía un correo electrónico.

Las medidas concretas podrían pasar como esto:

1. Un comando CreateEvent con una colección asociada de los usuarios para invitar, es recibido por el servidor.
2. Se crea un nuevo agregado Meeting y se llama a un método InviteUser para cada usuario que se va a invitar.
3. Cada vez que se invita a un usuario a un evento, se genera un evento de dominio UserWasInvitedToEvent.
4. Un remitente de notificación por correo electrónico recoge el evento de dominio y envía el correo electrónico de notificación.

Ahora mi pregunta es esta: ¿a dónde voy para que la información se incluya en el correo electrónico?

Digamos que deseo incluir una descripción del evento así como también el nombre del usuario. Como esto es CQRS, no puedo obtenerlo a través de mi modelo de dominio; ¡Todas las propiedades de los objetos de dominio son privadas! ¿Debo entonces consultar el lado de lectura? ¿O tal vez mover la notificación por correo electrónico a un servicio diferente por completo?

Answer 1

En CQRS, está separando el comando del lado de la consulta. Siempre querrá ir al lado de la consulta para obtener datos para un controlador de eventos determinado. La base de datos de escritura va a ser una base de datos separada que contiene los datos necesarios para crear sus objetos de dominio y no se optimizará para lecturas, sino para escrituras.

1. El dominio debe registrarse y enviar un evento EventCreated a los controladores de eventos/procesadores. Esto podría plantearse desde el constructor del agregado Meeting.
2. El componente de procesamiento de eventos seleccionará el evento EventCreated y actualizará la base de datos de consulta con los datos contenidos en el evento (es decir, el Id del evento y su nombre).
3. El dominio podría registrarse y enviar un evento UserWasInvitedToEvent a los procesadores de eventos.
4. Los procesadores de eventos recogerán el UserWasInvitedToEvent y actualizarán el almacén de consultas con los datos de informes necesarios.
5. Otro componente de procesamiento de eventos también captará el evento UserWasInvitedToEvent. Este proceso podría tener acceso a la base de datos de consultas y recuperar todos los datos necesarios para enviar el correo electrónico.

La base de datos de consultas no es más que una base de datos de informes, por lo que incluso podría tener una tabla específica que almacena todos los datos necesarios para el correo electrónico en un solo lugar.

Para organizar varios eventos diferentes en un solo controlador (suponiendo que los eventos se procesen en un orden diferente en diferentes momentos), puede utilizar el concepto de Saga en su bus de mensajes. NServiceBus es un ejemplo de un bus de mensajería que supports Saga's. Vea también esta pregunta de StackOverflow: NServiceBus Delayed Message Processing.