cqrs c#
CQRS sin Event Sourcing: ¿cuáles son los inconvenientes? (6)
CQRS existe debido a Event Sourcing, eso es lo que dijo su padre . Si puede permitirse el abastecimiento de eventos, debe hacerlo. Implementé un enfoque simple basado en SQL Server basado en Microsoft CQRS Journey .
Además de perder algunos de los beneficios de Event Sourcing, ¿existen otros inconvenientes para adaptar una arquitectura existente a CQRS sin la pieza de Event Sourcing?
Estoy trabajando en una aplicación grande y los desarrolladores deberían poder manejar la separación de la arquitectura existente en Comandos y Consultas en los próximos meses, pero pedirles que también agreguen el Evento de Aprovisionamiento en esta etapa sería un GRAN problema de una fuente de recursos. perspectiva. ¿Estoy cometiendo un sacrilegio al no incluir Event Sourcing?
Creo que Event Sourcing es lo que hace que la gente tenga miedo de CQRS. Y eso es por una razón. No es natural: cuando interactúas con algo en el mundo real, no necesitas tener un historial completo sobre este objeto.
"La fuente de eventos es un concepto completamente ortogonal para CQRS " ( fuente ): técnicamente, si no usa ES, no pierde nada de las características de CQRS.
No tengo idea de por qué Event Sourcing se considera la única base para resolver algunos problemas relacionados con "mensajes" como: duplicación / falta de mensajes, reordenación de mensajes y colisiones de datos, etc. No es cierto que si no usa Event La fuente no puede crear medios encapsulados para resolver tales problemas de otra manera.
Cómo veo formas alternativas de implementar los mensajes de CQRS usando otro principio de organización de datos que puede leer here .
Propongo un enfoque de "documentos firmados" donde usted trata sus datos no como composición de eventos de modificación, sino como composición de partes inmutables firmadas por usuarios responsables. Estoy seguro de que puede haber muchas otras soluciones para implementar el flujo de mensajes y el almacenamiento de datos. Y debe tener en cuenta su modelo de negocio al seleccionar cuál le gusta usar.
En mi opinión, estás cometiendo un gran error al no utilizar la fuente de eventos con CQRS.
En primer lugar, es casi seguro que tendrá problemas al sincronizar su modelo de consulta con el modelo de comando. Con un almacén de eventos, si el lado de la consulta no está sincronizado, simplemente debe volver a reproducir sus eventos para corregirlo. ¡Esa es la teoría de todos modos!
Pero con Event Sourcing, también puede almacenar el historial completo de todas las transacciones de la entidad. Y esto significa que puede decidir crear nuevas consultas y vistas después de la implementación. Estas son muy a menudo vistas que no serían posibles con CQRS sin origen en eventos. He escuchado a Greg Young dar el ejemplo de consultar artículos que se han agregado y luego eliminado de un carrito de compras. Con Event Sourcing esto es posible. Sin ES no es posible porque solo almacenas el estado final del carrito.
Estoy completamente de acuerdo con Dennis, ES no es una condición previa para CQRS, de hecho, CQRS por sí solo es bastante fácil de implementar y tiene el potencial de simplificar realmente su diseño.
Puedes encontrar una introducción suave here
En segundo lugar, ¿qué beneficios aporta CQRS por su cuenta?
- Simplifica los objetos de su dominio, eliminando todas las inquietudes de la consulta.
- Hace que la escala de código sea capaz, sus consultas se separan y se pueden sintonizar fácilmente
- A medida que recorre el diseño de su producto, puede agregar / eliminar / cambiar comandos / consultas individuales, en lugar de tratar con estructuras más grandes como un todo (por ejemplo, entidades, agregados, módulos).
- Los comandos y las consultas producen un vocabulario conocido para hablar con expertos en dominios. Otros patrones arquitectónicos (por ejemplo, tuberías y filtros, actores) utilizan términos y conceptos que pueden ser más difíciles de entender por los no programadores.
- Limita el uso de ORM (si usa uno), creo que los ORM aportan una complejidad injustificada si los usa para consultar, las abstracciones son agudas y pesadas, tratando de sintonizarlas es una yegua nocturna :) Usar un ORM solo en El lado del comando hace las cosas mucho más fáciles, el SQL antiguo es el mejor para las consultas, probablemente el uso de una biblioteca simple para convertir los conjuntos de resultados en DTO es lo más que necesita.
Más sobre cómo el diseño de beneficios de CQRS se puede encontrar here
Tampoco se olvide de los beneficios no tangibles de CQRS.
Si aún tienes dudas, puedes leer esto
Actualmente utilizamos CQRS para proyectos de complejidad media y hemos encontrado que es muy adecuado. Comenzamos usando un código de arranque personalizado y ahora hemos pasado a usar el Framework Axon para darnos algunos de los componentes de infraestructura.
Siéntase libre de enviarme un PM en caso de que quiera saber algo más específico.
Existe un problema fundamental en el patrón de fuente de eventos, es decir, los eventos en el almacén de eventos pueden no ser compatibles con sus controladores de eventos en su aplicación debido al cambio de código.
Dicho esto, siempre que modifique el controlador de eventos agregando nuevas funciones, debe pensar en la compatibilidad con versiones anteriores. Debe asegurarse de que su código siempre pueda manejar el mismo evento en diferentes etapas creadas por diferentes versiones de su código.
Cuando tu aplicación se vuelva más compleja, encontrarás dolor en el culo para que sea compatible con versiones anteriores.
Event Sourcing es opcional y en la mayoría de los casos complica las cosas más de lo que ayuda si se introduce demasiado pronto. Especialmente cuando la transición de una arquitectura heredada y aún más cuando el equipo no tiene experiencia con CQRS.
La mayoría de las ventajas que se atribuyen a ES se pueden obtener al almacenar sus eventos en un simple Registro de eventos. No tiene que abandonar su persistencia basada en el estado (pero a la larga probablemente lo hará, porque en algún momento se convertirá en el siguiente paso lógico).
Mi recomendación: la simplicidad es la clave. Dé un paso a la vez, especialmente cuando introduzca un cambio de paradigma tan dramático. Comience con CQRS simple, luego introduzca un Registro de eventos cuando usted (y su equipo) se hayan acostumbrado a los nuevos conceptos. Luego, si es necesario, cambie su persistencia a Event Sourcing y active el DBA ;-)