Cómo manejar conjunto de validación coherencia basada en CQRS?
-
04-10-2019 - |
Pregunta
Tengo un modelo de dominio bastante simple que implica una lista de raíces Facility
agregados. Dado que yo estoy usando CQRS y un evento-bus a eventos palanca elevada desde el dominio, ¿cómo podría manejar la validación de los conjuntos? Por ejemplo, decir que tengo el siguiente requisito:
- de
Facility
debe tener un nombre único.
Desde que estoy usando una base de datos coherentes con el tiempo en el lado de consulta, los datos en los que no se garantiza que sea precisa en el momento del evento processesor procesa el evento.
Por ejemplo, un FacilityCreatedEvent
está en la cola de procesamiento de eventos base de datos de consulta espera de ser procesados ??y escrita en la base de datos. Un nuevo CreateFacilityCommand
se envía al dominio para ser procesado. Los servicios de consulta de dominio la base de datos de lectura para ver si hay cualquier otro Facility
ya está registrado con ese nombre, pero vuelve falsa porque el CreateNewFacilityEvent
aún no ha sido procesado y por escrito a la tienda. El nuevo CreateFacilityCommand
ahora tendrá éxito y vomitar otra FacilityCreatedEvent
que estallar cuando los intentos de procesador al evento pueden escribir en la base de datos y hallazgos que otro Facility
ya existe con ese nombre.
Solución
La solución fui con era añadir una raíz agregada System
que podría mantener una lista de los nombres Facility
actuales. Al crear un nuevo Facility
, yo uso el agregado System
(sólo una System
como un objeto / producto único global) como una fábrica para ello. Si el nombre de la instalación dado ya existe, entonces se lanzará un error de validación.
Esto mantiene las restricciones de validación dentro del dominio y no se basa en el almacenamiento de consultas eventualmente consistentes.
Otros consejos
Tres enfoques se describen en consistencia eventual y conjunto de validación :
- Si el problema es poco frecuente o no es importante, tratar con él administrativamente, posiblemente mediante el envío de una notificación a un administrador.
- distribuir un evento DuplicateFacilityNameDetected, lo que podría poner en marcha un proceso de resolución automatizado.
- mantener un servicio que se sabe acerca de los nombres instalación utilizada, tal vez escuchando a los acontecimientos de dominio y mantener una lista de los nombres persistentes. Antes de la creación de cualquier nueva instalación, consulte con este servicio por primera vez.
También ver esta pregunta relacionada: validación Singularidad cuando se utiliza CQRS y eventos abastecimiento
En este caso, se puede aplicar un simple servicio de estilo CRUD que básicamente hace una inserción en una tabla de SQL con una restricción de clave primaria.
El inserto sólo ocurrirá una vez. Cuando los comandos duplicados con el mismo valor que sólo debe existir una vez golpea en el agregado, las llamadas agregados al servicio, el servicio falla la operación de inserción debido a una violación de la restricción de clave principal, genera un error, todo el proceso falla y eventos se generan, hay informes en el lado de consulta, tal vez un reporte de la falla en una tabla para la comprobación de la consistencia eventual donde el usuario puede consultar para conocer el estado del procesamiento de comandos. Para comprobar que, tal consulta una y otra vez el Estado del comando Ver Modelo con el GUID de comando.
Obviamente, cuando el comando contiene un valor que no existe en la tabla para la comprobación de la clave principal, la operación es un éxito.
La tabla de la restricción de clave primaria debe ser ser utilizado como un servicio, pero, debido a que ha implementado el abastecimiento de eventos, puede reproducir los eventos para reconstruir la tabla de restricción de clave primaria.
Debido a la singularidad de verificación se realiza antes de la escritura de datos, por lo que el mejor método es construir un servicio de seguimiento de eventos, que enviaría una notificación cuando el proceso de acabado o terminado.