aggregate - sourcing - Sagas CQRS-¿Las entendí bien?
saga pattern couchbase (3)
El término saga se usa comúnmente en las discusiones de CQRS para referirse a un fragmento de código que coordina y enruta mensajes entre contextos acotados y agregados. Sin embargo, para los fines de esta guía, preferimos utilizar el término administrador de procesos para referirnos a este tipo de artefacto de código. Hay dos razones para esto: existe una definición preexistente y bien conocida del término saga que tiene un significado diferente del que generalmente se entiende en relación con CQRS. El término administrador de procesos es una mejor descripción de la función realizada por este tipo de artefacto de código. Aunque el término saga se usa a menudo en el contexto del patrón CQRS, tiene una definición preexistente. Hemos elegido utilizar el término administrador de procesos en esta guía para evitar confusiones con esta definición preexistente. El término saga, en relación con los sistemas distribuidos, se definió originalmente en el documento "Sagas" de Hector Garcia-Molina y Kenneth Salem. Este documento propone un mecanismo que llama a una saga como una alternativa al uso de una transacción distribuida para administrar un proceso de negocios de larga ejecución. El documento reconoce que los procesos de negocios a menudo se componen de varios pasos, cada uno de los cuales involucra una transacción, y que la coherencia general se puede lograr agrupando estas transacciones individuales en una transacción distribuida. Sin embargo, en los procesos de negocios de larga ejecución, el uso de transacciones distribuidas puede afectar el rendimiento y la concurrencia del sistema debido a los bloqueos que deben mantenerse durante la transacción distribuida.
referencia: MSDN
Estoy tratando de entender las sagas , y mientras tanto tengo una forma específica de pensar en ellas, pero no estoy seguro de si entendí bien la idea. Por lo tanto, me gustaría elaborar y que otros me digan si es correcto o incorrecto.
En mi entendimiento, las sagas son una solución a la pregunta de cómo modelar procesos de larga ejecución . Medios de larga ejecución: involucrando múltiples comandos, múltiples eventos y posiblemente múltiples agregados. El proceso no se modela dentro de uno de los agregados participantes para evitar las dependencias entre ellos.
Básicamente, una saga no es más que un controlador de comando / evento que reacciona en comandos / eventos internos y externos . No contiene su propia lógica, es solo una máquina de estado (finita) y, por lo tanto, proporciona tareas como: Cuando ocurre el evento X, envíe el comando Y.
Las sagas se guardan en el almacén de eventos, así como los agregados, se correlacionan con una instancia agregada específica y, por lo tanto, se vuelven a cargar cuando se usa este agregado específico (o conjunto de agregados).
¿Es esto correcto?
Existen diferentes medios para implementar las sagas. Llegando desde controladores de eventos sin estado que publican comandos hasta transportar todo el estado y básicamente son los agregados del dominio. Udi Dahan escribió una vez un artículo sobre las Sagas como los únicos Agregados en un sistema (en su caso específico) correctamente modelado. Lo buscaré y actualizaré esta respuesta.
También está el concepto de sagas basadas en documentos.
Tu definición de Sagas suena bien para mí y yo también las definiría así.
El único cambio en su descripción que haría es que una saga es solo un manejador de eventos (no un comando) para el evento (s) y basado en el evento receptor y su estado interno construye un comando y lo envía al CommandBus para su ejecución.
Normalmente, una Saga solo tiene un evento único para iniciarse (StartByEvent) y varios eventos para hacer la transición (TransitionByEvent) al siguiente estado y el evento mutiples debe finalizar (EndByEvent).
En MSDN definieron Sagas como ProcessManager.