domain-driven-design - net - cqrs microsoft
Comunicación entre agregados en CQRS+DDD+Event Sourcing (2)
Cuando se utiliza Event Sourcing y CQRS, la forma más elegante (al menos en mi opinión) de comunicación inter-AR es la mensajería. Puedes ver el proyecto Ncqrs (será más fácil si eres un tipo .NET), particularmente la rama ''Mensajería''. 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 Enviar para enviar allí mensajes. Por medio de esta API, los clientes pueden invocar el comportamiento del modelo y el propio modelo puede comunicarse (entre los AR).
¿Cómo deben las raíces agregadas separadas (AR) comunicarse entre sí en un entorno basado en los principios de DDD usando un back-end agregado de origen de eventos?
Por ejemplo, tengo una raíz agregada de la Facility (AR) que tiene un método de fábrica responsable de crear una Booking AR. La Booking es una combinación sensible al tiempo de una Person AR y una Facility AR. Una Person solo puede ser reservada en una única Facility .
En DDD, habría mantenido referencias a la Booking en Person y Person en Facility . Sin embargo, al generar eventos para su uso en la fuente de eventos, creo que tratar de manejar la deserialización de eventos desde el back-end se volvería prohibitivo. Por lo tanto, he tomado como referencia solo la identificación de las ID únicas basadas en objetos de valor. Esto plantea un nuevo problema, sin embargo, cuando un método en un AR necesita llamar a otro método en otro AR: ¿cómo maneja esa situación? Golpee el repositorio de origen de evento desde el dominio AR?
¿Cuál es el caso de uso general en este escenario? ¿Me estoy acercando a todo esto mal?
Los límites de la raíz agregada definen un límite de coherencia. Dentro del agregado, la consistencia está garantizada. Afuera ... no lo es. Por lo tanto, no debe tener operaciones que abarquen varios agregados y deben ser coherentes. Si necesita una transacción que abarque dos agregados, debe revisar sus 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 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 duración (con compensación en lugar de retrotracción), o tomar decisiones comerciales basadas en lo que está sucediendo en el sistema a gran escala (incluso entre contextos limitados).