Escalabilidad de CQRS + EventSourcing

Question

Estoy intentando usar CQRS y EventSorcing en mi nuevo proyecto. Estoy siguiendo el camino sugerido por Greg Young hace varios años (implementación de Mark Nijhof - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/). Y tengo algunos problemas relacionados con la escalabilidad de esta solución.

Algunos puntos se mencionaron en el artículo this de Mark Nijhof. Pero el problema ahora es la parte Denormalizer, que es responsable de actualizar la base de datos de informes. Esta parte quiero que sea asincrónica, así que después de publicar eventos en el bus, quiero devolver el control inmediatamente. Sugerimos que Denormalizer podría implementarse como un servicio web independiente (WCF) que procesará los eventos entrantes y actualizará la base de datos del informe de forma sincronizada con lotes de comandos. Parece que podría ser un cuello de botella, por lo que también queremos agregar algo de escalabilidad en este momento: una solución de clúster. Pero en el caso del clúster no podemos controlar la secuencia de informes de las actualizaciones de la base de datos (o deberíamos implementar alguna lógica extraña y supongo que con errores que verificará las versiones de los objetos en el informe DB). Otro problema es la sostenibilidad de la solución: en caso de falla, perderemos las actualizaciones en el desnormalizador, en la medida en que no las conservemos en ninguna parte). Así que ahora estoy buscando solución a este problema (escalabilidad de Denormalizer) ¡cualquier pensamiento es bienvenido!

Answer 1

Para comenzar, definitivamente querrá tener el denormalizador alojado en un proceso separado. Desde allí, puede hacer que el dominio publique en su infraestructura de mensajería los eventos que ocurren en el dominio. Una estrategia fácil para ayudar a acelerar la desnormalización es dividir las cosas por tipo de mensaje/evento. En otras palabras, podría crear una cola separada para cada tipo de mensaje y luego hacer que el denormalizador se suscriba (utilizando un bus de mensajes) a los eventos correspondientes. La ventaja de esto es que no tiene mensajes apilados uno detrás del otro: todo comienza a ejecutarse en paralelo. Los únicos lugares en los que podría tener alguna disputa son las tablas que escuchan múltiples tipos. Aun así, ahora distribuyó la carga entre muchos puntos finales.

Siempre que use algún tipo de infraestructura de mensajería, no perderá los mensajes de evento cuando intenta desnormalizar. En cambio, después de un cierto número de intentos de falla, el mensaje se considerará "veneno" y se trasladará a una cola de errores. Simplemente monitoree la cola de errores para ver si hay problemas. Una vez que un mensaje se encuentra en la cola de errores, puede verificar sus registros para ver por qué está allí, solucionar el problema y luego volver a moverlo.

Otra consideración es que el ejemplo de Mark Nijhof es algo antiguo. Hay una serie de marcos CQRS disponibles, así como montones de consejos en el DDD/CQRS Google Group.