Manejo de concurrencia ES / CQRS

  

Esbozo mi comprensión aproximada de cómo una aplicación de ES / CQRS debe parecerse contextualizada a un caso de uso bancario simplificado (retirar dinero).

Este es el ejemplo perfecto de una aplicación de origen de eventos. Vamos a empezar.

Cada vez que se procesa o se reintenta un comando (comprenderá, tenga paciencia) se realizan los siguientes pasos:

1. el comando llega a un controlador de comandos, es decir, un servicio en el Application layer .
2. el controlador de comandos identifica el Aggregate y lo carga desde el repositorio (en este caso, la carga se realiza mediante new -ing una instancia Aggregate , recuperando todos los eventos emitidos previamente de este agregado y volviendo a aplicarlos) al Aggregate mismo; la versión de Aggregate se almacena para su uso posterior; después de que se aplican los eventos, el Aggregate se encuentra en su estado final, es decir, el saldo de la cuenta actual se calcula como un número)
3. el controlador de comandos llama al método apropiado en el Aggregate , como Account::withdrawMoney(100) y recopila los eventos producidos, es decir, MoneyWithdrewEvent(AccountId, 100) ; si no hay suficiente dinero en la cuenta (saldo < 100), se genera una excepción y se cancela todo; de lo contrario, se realiza el siguiente paso.
4. el controlador de comandos intenta mantener el Aggregate en el repositorio (en este caso, el repositorio es el Event Store ); lo hace agregando los nuevos eventos al Event stream si y solo si el version del Aggregate sigue siendo el que estaba cuando se cargó el Aggregate . Si la versión no es la misma, entonces se reintenta el comando; vaya al paso 1 . Si el version es el mismo, entonces los eventos se agregan al Event stream y el cliente recibe el estado Success .

Esta comprobación de versión se denomina bloqueo optimista y es un mecanismo de bloqueo general. Otro mecanismo es bloqueo pesimista cuando se bloquean otras escrituras (como no se ha iniciado) hasta que se completa la actual.

El término Event stream es una abstracción alrededor de todos los eventos que fueron emitidos por el mismo Agregado.

Debes entender que el Event store es solo otro tipo de persistencia donde se almacenan todos los cambios en un Agregado, no solo el estado final.

  

a) En este caso, el registro de eventos ya no es la fuente de la verdad, ¿cómo lidiar con eso? Además, volvimos al cliente de acuerdo, mientras que era totalmente incorrecto permitir el retiro, ¿es mejor en este caso usar bloqueos?

El almacén de eventos es siempre la fuente de la verdad.

  

b) Locks == deadlocks, ¿tiene alguna idea sobre las mejores prácticas?

Al utilizar el bloqueo optimista, no tiene bloqueos, simplemente reintente el comando.

De todos modos, ¡Cerraduras! = puntos muertos

  

Esbozo mi comprensión aproximada de cómo una aplicación de ES / CQRS debe parecerse contextualizada a un caso de uso bancario simplificado (retirar dinero).

Cerrar. El problema es que la lógica para actualizar tu "agregado" está en un lugar extraño.

La implementación más habitual es que el modelo de datos que su controlador de comandos mantiene en la memoria y la secuencia de eventos en el almacén de eventos se mantienen sincronizados.

Un ejemplo fácil de describir es el caso en el que el controlador de comandos realiza escrituras síncronas en el almacén de eventos y actualiza su copia local del modelo si la conexión con el almacén de eventos indica que la escritura se realizó correctamente.

Si el controlador de comandos necesita volver a sincronizarse con el almacén de eventos (porque su modelo interno no coincide con el de la tienda), lo hace cargando el historial de la tienda y reconstruyendo su propio estado interno.

En otras palabras, las flechas 2 y 3 (si están presentes) normalmente se conectarán al almacén de eventos, no a un almacén agregado.

  

coloque el id de la versión agregada junto con el evento en el almacén de eventos, de modo que si hay una discrepancia de versión en la modificación, no suceda nada

Las variaciones de esto son el caso habitual; en lugar de adjuntar a la secuencia en la secuencia de eventos, normalmente PUT a una ubicación específica en la secuencia; Si esa operación es incompatible con el estado de la tienda, la escritura falla y el servicio puede elegir el modo de falla apropiado (falla al cliente, reintente, fusione ...). El uso de escrituras idempotentes resuelve una serie de problemas en la mensajería distribuida, pero, por supuesto, requiere tener una tienda que admita una escritura idempotente.