Diseño impulsado por dominio y eventos de dominio

Question

Soy nuevo en DDD y estoy leyendo artículos ahora para obtener más información. Uno de los articles se centra en eventos de dominio (DE). Por ejemplo, enviar un correo electrónico es un evento de dominio generado después de que se cumplan algunos criterios al ejecutar un fragmento de código.

ejemplo

Código muestra una manera de manejar los eventos de dominio y es seguido por este párrafo

Tenga en cuenta que el código anterior se llevará a cabo en el mismo subproceso dentro de la misma transacción que el trabajo regular del dominio para que debe evitar realizar cualquier actividad de bloqueo, como usar SMTP o servicios web. En su lugar, prefiera usar mensajes unidireccionales para comunicarse con otra cosa que haga esas actividades de bloqueo.

Mis preguntas son

1. Es esto un problema general en el manejo de DE? ¿O es solo preocupación de la solución en el artículo mencionado?
2. Si los eventos de dominio se producen en una transacción y el sistema no los manejará de forma síncrona, ¿cómo deberían manejarse?
3. Cuando decido serializar estos eventos y dejar que el planificador (o cualquier otro mecanismo) los ejecute, ¿qué ocurre cuando se retrotrae la transacción? (en el evento del artículo aparece en el código ejecutado en la transacción) ¿quién los cancelará (cuando no se mantienen en la base de datos)?

Gracias

Answer 1

Es un período problema general no importa DDD

En general, en cualquier sistema que se requiere para responder de manera performant (por ejemplo, un servidor Web, cualquier actividad de larga ejecución debe ser manejado de forma asíncrona con el proceso de activación.

Esto significa cola.

Retrotracción transacción debería eliminar elemento de la cola.

Por supuesto, ahora necesita mecanismos adicionales para manejar la situación en la que el elemento en la cola no puede procesar, es decir, el correo electrónico no se envía, también debe tenerlo en su código de activación, teniendo un proceso posterior CONFIAR en que el proceso anterior ya haya ocurrido va a causar problemas en algún momento.

En resumen, su mecanismo de puesta en cola debería ser en sí mismo transaccional y permitir reintentos y debe pensar en toda la cadena de eventos como un flujo de trabajo.