CQRS: ¿cuándo enviar un mensaje de confirmación?

Question

Ejemplo: Las reglas comerciales establecen que el cliente debe recibir un mensaje de confirmación (correo electrónico o similar) cuando se realiza un pedido.

Digamos que un NewOrderRegisteredEvent se envía desde el dominio y es recogido por un oyente de eventos que envía el mensaje de confirmación. Cuando se hace eso, otro manejador de eventos lanza una excepción o algo más sale mal y la unidad de trabajo se revierte. Ahora hemos enviado al usuario un mensaje de confirmación de algo que se ha retrotraído.

¿Cuál es la forma "cqrs" de resolver problemas como este en los que desea hacer algo una vez que se ha comprometido una unidad de trabajo? Otro factor que complica es la repetición de eventos. No quiero que los mensajes de confirmación antiguos se vuelvan a enviar cada vez que reproduzco los eventos grabados para construir una nueva vista/proyección.

Mi mejor teoría hasta el momento: acabo de comenzar a investigar el fascinante mundo de las cqrs y me preguntaba si esto es algo que se implementaría como una saga. Si una saga es como una máquina de estados donde cada transición solo puede tener lugar una sola vez, entonces supongo que eso resolvería este problema. Sólo tengo un tiempo difícil visualizar cómo va a encajar con los eventos en el bus de mando y dominio ..

Answer 1

1. Un evento solo debe ocurrir después de que la transacción se haya completado. Si algo sale mal y hay un retroceso, entonces el evento no ocurrió desde un punto de vista externo. Por lo tanto, no debería publicarse en absoluto. Aunque un evento OrderRegistrationFailed podría publicarse si es necesario.

2. No querrá que se envíe el correo a menos que el comando se haya ejecutado correctamente.

   Primero algunas razones por las cuales el controlador de comando - como se propone en otra respuesta - sería el lugar equivocado: en algunas circunstancias, el controlador de comando no podría decir si el comando finalmente tendrá éxito o no. Hacer que el manejador de comandos invoque el envío del correo también pondría el conocimiento del proceso dentro del controlador de comando, lo que rompería el SRM y uniría las reglas comerciales con la capa de aplicación.

   El correo debe enviarse después del hecho, es decir, desde un controlador de eventos.

   Para evitar que este controlador se dispare durante la reproducción, simplemente no puede registrarlo. Esto funciona de manera similar a cómo prueba su aplicación. Solo registra los manejadores que realmente necesita.

   sistema
   • Producción -> Registrar todos los controladores de eventos
   • Pruebas -> registrar solamente los controladores de eventos probados
   • Replay -> Registrar sólo los controladores de proyección/desnormalización

Otra - aún más débilmente acoplado, aunque un poco más complejo - la posibilidad sería tener un Saga manejar el NewOrderRegisteredEvent y emitir un comando SendMail al appr contexto limitado de merecido (gracias, Yves Reynhout, por señalar esto en los comentarios de la pregunta).

Answer 2

Hay dos soluciones posibles

1) La publicación del evento y el control del evento (es decir, el correo electrónico) son parte de una sola transacción. En este caso, su marco de transacciones se ocupa de ello por usted. Si el correo electrónico falla, se revierte el evento. Es probable que vuelva a intentar el comando. Esto es conceptualmente limpio y fácil de pensar. Ningún evento ha terminado de publicarse hasta que todos los que tienen algo que decir al respecto hayan expresado su opinión. Sin embargo, en términos prácticos, esto puede ser doloroso, ya que normalmente implica transacciones distribuidas. Estos son difíciles de conseguir. ¿Puede su cliente de correo electrónico inscribirse en la misma transacción que la base de datos que está llevando a cabo sus eventos?

2) La publicación del evento es transaccional, pero los manejadores de eventos tratan las transacciones a su manera. El controlador de eventos que envía correos electrónicos podría hacer un seguimiento de los eventos que había visto. Si se bloqueaba, solicitaría eventos antiguos y los procesaría. Podría tomar una decisión comercial sobre qué tan grande sería si las personas tuvieran correos electrónicos perdidos o duplicados. (Para las transacciones relacionadas con el dinero, probablemente la respuesta sea que no debe permitirlo).

La solución (2) es típicamente lo que ve promovido en los círculos DDD/CQRS ya que es la solución menos flexible. La solución (1) es bastante práctica en un sistema pequeño donde la tienda de eventos y las proyecciones están en una única base de datos y las proyecciones no cambian con frecuencia. La solución (2) permite que una diversidad de manejadores de eventos trabajen a su manera. La solución (1) puede ocasionar que muchas preocupaciones que no se superponen se encripten. En este caso, las reglas comerciales de su orden no se completan hasta que se resuelven las muchas cosas extrañas que ocurren en el envío de correos electrónicos. Por un lado, puede ralentizarte un poco.

Si el envío del correo electrónico fue más interesante que "vio el evento, envió el correo electrónico", entonces tiene razón, es posible que tenga una saga o un flujo de trabajo en sus manos. El correo electrónico en operaciones grandes es a menudo un sistema complejo por derecho propio, del cual es improbable que tenga que implementar gran parte. Solo necesita asegurarse de poner su correo electrónico en una cola de solicitudes de algún tipo (utilizando el método (2)), y es probable que el sistema de correo haga reintentos/lotes/evitación de correo no deseado/trabajo nocturno/etc.