Inter-Agregado Comunicación en CQRS + DDD + Event Sourcing
¿Cómo debería separarse aggregate roots (AR) comunicarse entre sí en un entorno construido sobre principios DDD utilizando un back-end aggregate de origen de eventos?
Por ejemplo, tengo un Facility aggregate root (AR) que tiene un método factory responsable de crear un Booking AR. El Booking es una combinación sensible al tiempo de un Person AR y un Facility AR. Un Person solo se puede reservar en un único 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 el abastecimiento de eventos, creo que tratar de manejar la deserialización de eventos desde el back-end se volvería prohibitivo. Por lo tanto, solo he mantenido las referencias a los ID únicos basados en objetos de valor. Esto trae un nuevo problema, sin embargo, cuando un método en una AR necesita llamar a otro método en otra AR? ¿cómo maneja esa situación? Golpear el repositorio de origen de eventos desde el dominio AR?
Cuál es el uso general caso en este escenario? ¿Estoy enfocando esto mal?
2 answers
Los límites de raíz agregados 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 abarcan varios agregados y deben ser consistentes. 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 complicado, puede definir un proceso, una máquina de estados que escuchará eventos y enviará comandos a agregados. Los procesos se pueden utilizar para definir transacciones de larga duració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 limitados).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-02-02 20:16:11
Cuando se utiliza el Aprovisionamiento de eventos y CQRS, la forma más elegante (al menos en mi opinión) de comunicación inter-AR es la mensajería. Puedes mirar el proyecto Ncqrs (será más fácil si eres un chico de.NET), particularmente la rama 'Messaging'. La idea es que ARS implemente la interfaz IMessageHandler para cada tipo de mensaje que manejen y la clase base AR expone el método Send para enviar mensajes allí. Por medio de esta API, los clientes pueden invocar el comportamiento del modelo y el propio modelo puede comunicarse (entre ARs).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-01-19 09:09:07