Sistema CQRS conectado ocasionalmente
Problema:
Dos empleados (A y B) se desconectan al mismo tiempo mientras editan el cliente n. ° 123, dicen la versión n. ° 20, y mientras están desconectados continúan realizando cambios ...
Escenarios:
1 - Los dos empleados editan el cliente # 123 y realizan cambios en uno o más atributos idénticos.
2 - Los dos empleados editan el cliente # 123 pero NO hacen los mismos cambios (se cruzan sin tocarse).
... ambos vuelven a estar en línea, se agrega el primer empleado A, cambiando así al cliente a la versión # 21, luego el empleado B, todavía en la versión # 20
Preguntas:
¿Qué cambios mantenemos en el escenario 1?
¿Podemos hacer una fusión en el escenario 2, cómo?
Contexto:
1 - Sistema de estilo CQRS + Event Sourcing
2 - Use Event Sourcing Db como cola
3 - Consistencia eventual en el modelo de lectura
4 - API RESTful
EDIT-1: aclaraciones basadas en las respuestas hasta ahora:
Para realizar una fusión granulada con multas, ¿necesitaré tener un comando para cada campo en un formulario, por ejemplo?
Arriba, los comandos finamente detallados para ChangeName, ChangeSupplier, ChangeDescription, etc., cada uno con su propia marca de tiempo permitiría la fusión automática en el caso de que A & B actualizaran ChangedName?
Edit-2: seguimiento basado en el uso de una tienda de eventos en particular:
Parece que haré uso de @GetEventStore para la persistencia de mis secuencias de eventos.
Utilizan la concurrencia optimista de la siguiente manera:
Cada evento en una secuencia incrementa la versión de la secuencia en 1
Las escrituras pueden especificar una versión esperada, haciendo uso del encabezado ES-ExpectedVersion en los escritores
-1 especifica que la secuencia no debería existir
0 y superior especifica una versión de transmisión
Las escrituras fallarán si la transmisión no se encuentra en la versión, si vuelve a intentarlo con un nuevo número de versión esperado o si reprocesó el comportamiento y decidió que está bien si así lo elige.
Si no se especifica una versión esperada de ES, el control de concurrencia optimista está deshabilitado
En este contexto, la concurrencia optimista no solo se basa en la ID del mensaje, sino también en el evento #