Solución:
Aquí está mi opinión sobre esto.
-
CQRS + ES puede simplificar mucho las cosas en sistemas de software complejos al tener objetos de dominio ricos, modelos de datos simples, seguimiento del 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 simplifica la separación de responsabilidades entre los desarrolladores. Por ejemplo, un desarrollador junior puede trabajar únicamente con el lado de lectura sin tener que tocar la lógica empresarial.
-
Seguro que las copias de datos requerirán más espacio en disco. Pero el almacenamiento es relativamente barato en estos días. Es posible que sea 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 lo convierte en un flujo de trabajo más optimizado. Además, es mucho más fácil crear redundancia en el sistema sin una base de datos monolítica.
-
No considero que un mayor uso de memoria sea un problema. La hidratación del objeto comercial debe realizarse a pedido. Los objetos no deben guardar referencias a eventos que ya han sido persistentes. Y la hidratación de eventos debe ocurrir solo cuando los datos persisten. En el lado de lectura, no tiene Entity -> DTO -> ViewModel conversiones que generalmente ocurrieron en sistemas escalonados, y no tendría ningún tipo de seguimiento de cambio de objeto que los ORM con todas las funciones suelen tener. La mayoría de los sistemas realizan significativamente más lecturas que escrituras.
-
Un tiempo de arranque más largo puede ser un problema leve si está utilizando varias bases de datos heterogéneas debido a la inicialización de varios contextos de datos. Sin embargo, si está utilizando algo simple como ADO .NET para interactuar con la tienda 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 demasiado la forma en que accede a los datos. Ese es en realidad 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 gastos generales de redistribución 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ía 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 una gran cantidad de usuarios simultáneos, debería diseñarse teniendo en cuenta la coherencia final. Hay casos en los que tendría raíces agregadas o límites de contexto que no usan CQRS para evitar una eventual consistencia. Tiene sentido para las partes no colaborativas del dominio.
-
Puede consultar eventos en un formato serializado como JSON o XML, si elige la base de datos adecuada para el almacén de eventos. Y eso solo debe hacerse con fines analíticos. Nada dentro del sistema debe consultar el almacén de eventos por otra cosa que no sea la identificación de raíz agregada y el tipo de evento. Esos datos se indexarían y vivirían fuera del evento serializado.
Solo para comentar el punto 5. Me han dicho que Facebook usa ES con Eventual Consistency, por lo que a veces puedes ver una publicación desaparecer y reaparecer después de haberla publicado.
Por lo general, el modelo de lectura al que accede su navegador se encuentra ‘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 su publicación aún no se ha propagado a ese modelo de lectura, verá que su propia publicación desaparece solo para reaparecer más tarde.
Sé que han pasado casi 3 años desde que se hizo esta pregunta, pero aún así, este artículo puede ser útil para alguien. Los puntos clave son
- Escalado con instantáneas
- Visibilidad de datos
- Cambio de esquema
- Tratar con dominios complejos
- Necesito explicárselo a la mayoría de los miembros nuevos del equipo.