sourcing - ddd and cqrs

Lea los enfoques de implementación lateral utilizando CQRS

Question

Me mudé al proyecto que está utilizando activamente la fuente de eventos CQRS +. Desde el primer vistazo, se implementó de acuerdo con todos esos libros y blogs, pero finalmente me di cuenta de lo que es realmente molesto en la implementación.

Aquí está la arquitectura CQRS:

Originalmente tomé esta foto desde here .

Como podemos ver en la imagen, el lado de lectura recibe eventos de la cola y los pasa uno por uno a diferentes conjuntos de proyecciones (denormalizadores) y luego los ViewModels resultantes se guardan a través del método AddOrUpdate en, por ejemplo, DB. Entonces, según entiendo, en la imagen, el desnormalizador puede depender solo del evento en sí, más los datos de la base de datos de lectura. Por ejemplo:

1. Vista de cuenta ya almacenada en la db.
2. El evento EmailChanged llega
3. Leemos la vista de la cuenta desde el DB
4. Aplicando un cambio de correo electrónico a él
5. Guardamos la cuenta de nuevo en DB.

Otro caso (contando el número de algunos artículos, digamos órdenes):

1. Llega el evento OrderCreated
2. Leemos el ViewModel que representa el número de pedidos recibidos anteriormente
3. Incrementa y guarda esto.

Lo que tenemos en nuestro proyecto: utilizamos todos esos eventos solo como un notificador de que algo cambió en el modelo de dominio. Por lo tanto, lo que hacemos:

1. Tomamos repositorio de dominio y leemos todos los agregados necesarios. Haciendo esto obtenemos el estado más reciente de ellos.
2. Simplemente construimos el objeto ViewModel desde cero
3. Guardar objeto recién creado en Db

El enfoque que usamos en nuestro proyecto me parece un poco extraño, aunque no puedo ver todos sus inconvenientes. Si necesitamos reconstruir nuestro lado de lectura, agregamos denormalizer "activo" y la próxima vez que reciba un evento en particular, recreará el nuevo modelo de vista.

Si usamos el enfoque de los libros, tendré que tener una lógica de utils separada en algún lugar fuera de mi sistema para la reconstrucción. Lo que necesitamos para esto:

1. Deja caer el lado de lectura
2. Lee todos los eventos de la tienda de eventos desde el principio.
3. Pasalos por las proyecciones.

Así que mi pregunta es:
¿Cuál es el enfoque correcto aquí?

Answer 1

El enfoque que usamos en nuestro proyecto me parece un poco extraño, aunque no puedo ver todos sus inconvenientes.

Un inconveniente importante es que al recibir el evento, debe realizar una llamada adicional al repositorio del agregado correspondiente. Esto significa que este repositorio debe estar expuesto, ya sea directamente o como un servicio. Además de mayores dependencias es la IO adicional.

Para la reconstrucción de un almacén de eventos, el enfoque que describe es el método generalmente aceptado. Un enfoque descrito here hace uso de un registro de eventos dedicado a la reconstrucción de proyecciones. Esto se puede utilizar para abordar problemas de rendimiento durante la reconstrucción. También eche un vistazo a las vistas CQRS escalables y simples en la nube y en la lista de correo DDD / CQRS .