Me doy cuenta de que la pregunta anterior probablemente genera algunos '¿qué?', pero déjame intentar explicarte:
Estoy tratando de envolver mi cabeza en un par de conceptos relacionados, básicamente el patrón Saga ( enlace ) en combinación con Event-sourcing (un concepto DDD: enlace )
Un buen post que lo envuelve junto: enlace
Llego a la pregunta en un minuto, pero creo que primero tengo que intentar resumir lo que entiendo (lo que podría estar mal, así que corríjalo si ese es el caso) ya que esto podría impactar por qué Estoy haciendo la pregunta para comenzar con:
- El patrón Saga es un tipo de agente que, dado que una acción (usuario final, automatizado, etc. esencialmente cualquier cosa que vaya a cambiar los datos) divide esa acción en actividades comerciales y envía cada una de estas actividades como mensajes a un Bus de mensajes que, a su vez, lo envía a las respectivas raíces agregadas para ser atendido.
- Estas raíces agregadas pueden operar de forma completamente autónoma (buena separación de inquietudes, gran escalabilidad, etc.)
- Una instancia de Saga en sí misma no contiene ninguna lógica de negocios, que está contenida en las raíces agregadas a las que envía las actividades. La única "lógica" contenida en la Saga es la lógica de "proceso", (que a menudo se implementa como un Statemachine), que determina en función de las acciones recibidas (así como los eventos de seguimiento) qué hacer (es decir, qué actividades enviar)
- Los patrones Saga implementan un tipo de patrón de transacción distribuida. Es decir: cuando una de las raíces agregadas (que de nuevo funciona de forma autónoma, sin conocer las demás existentes) falla, es posible que la acción completa tenga que revertirse.
- Esto se implementa al tener todas las raíces agregadas, al completar su informe de actividades de vuelta a la Saga. (En caso de éxito y error)
- En caso de que todas las raíces agregadas devuelvan un éxito, la máquina de estadísticas interna si la Saga determina qué hacer a continuación (o decide que está hecho)
- En caso de falla, la Saga emite a todas las raíces agregadas que participaron en la última acción llamada Acción de Compensación, es decir: una acción para deshacer la última acción que hizo cada una de las raíces agregadas.
- Esto podría ser simplemente hacer un 'Minus 1 vote' si la acción fue "más 1 voto 'pero podría ser más complicado como restaurar una entrada de blog a su versión anterior.
- El aprovisionamiento de eventos (consulte el blogpost que combina los dos) tiene como objetivo externalizar el guardado de los resultados de cada una de las actividades que cada una de las raíces agregadas realiza en un Almacén de eventos centralizado (los cambios se denominan "eventos" en este contexto)
- Este almacén de eventos es la "versión única de la verdad" y se puede usar para reproducir el estado de todas las entidades simplemente mediante la iteración de los eventos almacenados (esencialmente como un registro de eventos)
- Combinar los dos (es decir, dejar que las raíces agregadas utilicen la fuente de eventos para subcontratar guardando sus cambios antes de informar a la Saga) permite muchas posibilidades agradables, una de las cuales concierne a mi pregunta ...
Sentí que necesitaba sacarme esto de mi hombro, ya que es mucho para agarrarlo de una sola vez. Dado este contexto / mentalidad (de nuevo, corríjalo si es incorrecto)
la pregunta: cuando una raíz agregada recibe una Acción de Compensación y si esa raíz agregada ha subcontratado sus cambios de estado mediante el uso de Evento, la Acción de Compensación en todas las situaciones no sería una eliminación. del último evento en la tienda de eventos para esa raíz agregada dada? (Suponiendo que la implementación persistente permita eliminaciones)
Eso tendría mucho sentido para mí (y sería otro gran beneficio de esta combinación), pero como dije, podría estar haciendo estas suposiciones basadas en una comprensión incorrecta / incompleta de estos conceptos.
Espero que esto no haya sido demasiado largo.
Gracias.