cqrs - usar - ventajas y desventajas de tagcrowd

¿Cuáles son las desventajas de usar el suministro de eventos y CQRS? (4)

La fuente de eventos y CQRS es excelente porque hace que los desarrolladores de rids se queden atrapados en una base de datos pre-modelada con la que el desarrollador tiene que trabajar durante toda la vida de la aplicación, a menos que haya un proyecto de migración de big data. CQRS y ES también tienen otros beneficios como la ampliación del almacén de eventos, el registro de auditoría, etc., que ya se encuentran en Internet.

¿Pero cuáles son las desventajas?

Aquí hay algunas desventajas en las que puedo pensar después de investigar y escribir pequeñas aplicaciones de demostración.

Complejo: Algunas personas dicen que ES es complejo. Pero diría que tener una aplicación compleja es mejor que un modelo de base de datos complejo en el que solo puede ejecutar consultas muy restringidas usando un lenguaje de consulta (varias uniones, índices, etc.). Me refiero a que algunos lenguajes de programación como Scala tienen una biblioteca de colecciones muy rica que es muy flexible para producir agregaciones muy complejas y también está Apache Spark, que facilita la consulta de colecciones distribuidas. Pero las bases de datos siempre estarán restringidas a sus capacidades de lenguaje de consulta y la distribución de las bases de datos es más difícil que el código de la aplicación distribuida (¡Simplemente implemente otra instancia en otra máquina!) .
Gran uso de espacio en disco : el almacén de eventos puede terminar usando una gran cantidad de espacio en disco para almacenar eventos. ¿Pero podemos programar una limpieza cada pocas semanas y crear instantáneas y podemos guardar eventos históricos localmente en un HD externo solo en caso de que necesitemos eventos antiguos en el futuro?
Alto uso de memoria : el estado de cada objeto de dominio se almacena en la memoria, lo que puede aumentar el uso de la RAM y, a todos nosotros, el coste de la RAM. ¡¡GRAN PROBLEMA!! porque soy pobre ¿Alguna solución a esto? ¿Se puede usar Sqlite en lugar de almacenar el estado en la memoria? ¿Estoy haciendo las cosas más complejas al introducir varias instancias de Sqlite en mi aplicación?
Tiempo de arranque más prolongado : en caso de fallo o actualización de software, el arranque es lento dependiendo del número de eventos ¿Pero podemos usar instantáneas para resolver esto?
Consistencia eventual : Problema para algunas aplicaciones. Imagínese si Facebook utilizara el Servicio de abastecimiento de eventos con CQRS para almacenar publicaciones y considerar cuán ocupado está el sistema de Facebook y si publicara una publicación, vería mi publicación de FB al día siguiente :)
Eventos serializados en el almacén de eventos : los almacenes de eventos almacenan eventos como objetos serializados, lo que significa que no podemos consultar el contenido de los eventos en el almacén de eventos, lo cual no es recomendable. Y no podremos agregar otro atributo al evento en el futuro. ¿La solución sería almacenar eventos como objetos JSON en lugar de eventos serializados? Pero es una buena idea ? ¿O agregar más eventos para admitir el cambio al objeto de evento original?

¿Alguien puede por favor comentar las desventajas que mencioné aquí y corregirme si me equivoco y sugerir alguna otra que pueda haber perdido?

La fuente de eventos y CQRS es excelente porque hace que los desarrolladores de rids se queden atrapados en una base de datos pre-modelada con la que el desarrollador tiene que trabajar durante toda la vida de la aplicación, a menos que haya un proyecto de migración de big data.

Este es un gran error. Las bases de datos relacionales se inventaron exactamente para la evolución del modelo (gracias a tablas bidimensionales simples en lugar de estructuras jerárquicas predefinidas). Con vistas y procedimientos que aseguran la encapsulación del acceso a los datos, el modelo lógico y físico puede evolucionar de forma independiente. Esta es también la razón por la que SQL define DDL y DML en el mismo idioma. Algunos RDBMS también permiten que todas esas evoluciones se versionen y se implementen en línea (entrega continua) como una edición basada en Oracle Edition.

Las estructuras de datos grandes están predefinidas y solo se pueden leer con el código desarrollado para esta estructura. Está bien cuando se consume de inmediato, pero tendrá dificultades para leerlo 10 años después sin la versión exacta y el compilador o intérprete de idiomas.

Aquí está mi opinión sobre esto.

CQRS + ES puede simplificar mucho las cosas en sistemas de software complejos al tener objetos de dominio enriquecidos, modelos de datos simples, seguimiento de historial, más visibilidad de los problemas de concurrencia, escalabilidad y mucho más. Requiere una forma diferente de pensar en los sistemas, por lo que podría ser difícil encontrar desarrolladores calificados. Pero CQRS hace que sea más sencillo separar las responsabilidades entre los desarrolladores. Por ejemplo, un desarrollador junior puede trabajar exclusivamente con el lado de lectura sin tener que tocar la lógica de negocios.
Las copias de los datos requerirán más espacio en el disco. Pero el almacenamiento es relativamente barato en estos días. Puede ser necesario que el equipo de soporte de TI realice más copias de seguridad y planifique cómo restaurar el sistema en caso de que las cosas salgan mal. Sin embargo, la virtualización de servidores en estos días hace que sea un flujo de trabajo más ágil. Además, es mucho más fácil crear redundancia en el sistema sin una base de datos monolítica.
No considero un mayor uso de memoria un problema. Hidratación de objetos de negocios debe hacerse bajo demanda. Los objetos no deben mantener referencias a eventos que ya han sido persistidos. Y la hidratación del evento debe ocurrir solo cuando los datos persisten. En el lado de lectura, no tiene conversiones de Entidad -> DTO -> ViewModel que usualmente ocurrían en sistemas escalonados, y no tendría ningún tipo de seguimiento de cambio de objeto que los ORM con todas las funciones normalmente tienen. La mayoría de los sistemas realizan significativamente más lecturas que escrituras.
Un tiempo de arranque más largo puede ser un pequeño problema si está utilizando varias bases de datos heterogéneas debido a la inicialización de diversos contextos de datos. Sin embargo, si está utilizando algo simple como ADO .NET para interactuar con el almacén de eventos y un micro-ORM para el lado de lectura, el sistema se iniciará en frío más rápido que cualquier ORM con todas las funciones. Lo importante aquí es no complicar en exceso la forma en que accede a los datos. Eso es realmente un problema que se supone que CQRS debe resolver. Y como dije antes, el lado de lectura debe modelarse para las vistas y no tener ninguna sobrecarga de re-mapeo de datos.
La confirmación en dos fases puede funcionar bien para sistemas que no necesitan escalar para miles de usuarios en mi experiencia. Deberá elegir bases de datos que funcionen bien con el coordinador de transacciones distribuidas. PostgreSQL puede funcionar bien para leer y escribir modelos separados, por ejemplo. Si el sistema necesita escalar para un gran número de usuarios concurrentes, debería diseñarse teniendo en cuenta la consistencia final. Hay casos en los que tendría raíces agregadas o límites de contexto que no utilizan CQRS para evitar la eventual coherencia. Tiene sentido para las partes no colaborativas del dominio.
Puede consultar eventos en formato serializado como JSON o XML, si elige la base de datos correcta para el almacén de eventos. Y eso solo debe hacerse con fines analíticos. Nada dentro del sistema debería consultar el almacén de eventos por otra cosa que no sea el ID raíz agregado y el tipo de evento. Esos datos se indexarán y vivirán fuera del evento serializado.

Sé que han pasado casi 3 años desde que se hizo esta pregunta, pero este artículo puede ser útil para alguien. Los puntos clave son

Escalado con instantáneas
Visibilidad de los datos.
Cambio de esquema
Tratar con dominios complejos
Necesito explicárselo a la mayoría de los nuevos miembros del equipo.

Solo para comentar sobre el punto 5. Me han dicho que Facebook usa ES con la consistencia eventual, por lo que a veces puedes ver que una publicación desaparece y vuelve a aparecer después de que la hayas publicado.

Por lo general, el modelo de lectura al que está accediendo su navegador está ubicado cerca de usted, pero después de hacer una publicación, el SPA cambia a un modelo de lectura que está cerca de su modelo de escritura. La proximidad entre el modelo de escritura (eventos) y el modelo de lectura significa que puedes ver tu propia publicación.

Sin embargo, 15 minutos después, su SPA vuelve al primer modelo de lectura más cercano. Si el evento que contiene tu publicación aún no se ha propagado a ese modelo de lectura, verás que tu propia publicación desaparecerá y volverá a aparecer más tarde.