Comunicación entre agregados en CQRS + DDD + Event Sourcing

Question

¿Cómo se debe comunicar aggregate roots (AR) entre sí en un entorno basado en los principios DDD utilizando un back-end agregado de origen de eventos?

Por ejemplo, tengo una raíz agregada Facility (AR) que tiene un método de fábrica responsable de crear un Booking AR. El Booking es una combinación temporal de Person AR y Facility AR. Un Person solo se puede reservar en un solo Facility.

En DDD, lo habría celebrado referencias al Booking en Person y Person en Facility. Sin embargo, al generar eventos para su uso en el suministro de eventos, creo que tratar de manejar la deserialización del evento desde el back-end sería prohibitivo. Por lo tanto, me he limitado a llevar a cabo referencias al valor de los id únicos basados ​​en objetos. Esto trae a colación un nuevo problema, sin embargo, cuando un método en un AR necesita llamar a otro método en otro AR: ¿cómo manejas esa situación? Pulse el repositorio de origen del evento desde el dominio AR?

¿Cuál es el caso de uso general en este escenario? ¿Me estoy acercando a todo esto mal?

Answer 1

Los límites de la raíz agregada definen un límite de consistencia. Dentro del agregado, la consistencia está garantizada. Fuera ... no lo es. Por lo tanto, no debe tener operaciones que abarquen varios agregados y tengan que ser consistentes. Si necesita una transacción que abarca dos agregados, debe revisar los límites agregados.

Para las cosas que suceden fuera del agregado, debe tener un controlador de eventos que envíe un comando a otros agregados. Si la lógica de las acciones entre los agregados es más complicada, puede definir un proceso, una máquina de estado que escuchará los eventos y enviará los comandos a los agregados. Los procesos se pueden usar para definir transacciones de larga ejecución (con compensación en lugar de reversión), o tomar decisiones comerciales basadas en lo que está sucediendo en el sistema a gran escala (incluso entre contextos acotados).

Answer 2

Al utilizar Event Sourcing y CQRS, la manera más elegante (al menos en mi opinión) de comunicación entre AR es la mensajería. Puede mirar el proyecto Ncqrs (será más fácil si es un tipo .NET), particularmente la rama 'Mensajes'. La idea es que los AR implementen la interfaz IMessageHandler para cada tipo de mensaje que manejan y la clase base AR expone el método Send para enviar allí los mensajes. Mediante esta API, los clientes pueden invocar el comportamiento del modelo y el propio modelo puede comunicarse (entre AR).