Después de de una extensa búsqueda de datos hemos podido resolver este asunto que presentan algunos los lectores. Te ofrecemos la respuesta y nuestro objetivo es servirte de mucha ayuda.
Solución:
Event Sourcing es opcional y, en la mayoría de los casos, complica las cosas más de lo que ayuda si se presenta demasiado pronto. Especialmente cuando se hace 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 almacenando sus eventos en un registro de eventos simple. 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 sencillez es la key. Haga un paso a la vez, especialmente al introducir 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 😉
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.
Puede encontrar una introducción fluida aquí.
En segundo lugar, ¿qué beneficios aporta CQRS por sí solo?
- Simplifica los objetos de su dominio, eliminando todas las inquietudes de las consultas
- Hace que el código sea escalable, sus consultas están separadas y se pueden ajustar fácilmente
- A medida que itera sobre 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 consultas producen un vocabulario bien conocido para hablar con expertos en el dominio. Otros patrones arquitectónicos (p. ej., conductos y filtros, actores) utilizan términos y conceptos que pueden ser más difíciles de comprender para quienes no son programadores.
- Limita el uso de ORM (si usa uno), creo que los ORM aportan una complejidad injustificada si intenta usarlos para realizar consultas, las abstracciones tienen fugas y son pesadas, tratar de ajustarlas es una pesadilla 🙂 Usar un ORM solo en el lado del comando hace las cosas mucho más fáciles, el SQL simple y antiguo es el mejor para las consultas, probablemente usar una biblioteca simple para convertir conjuntos de resultados en DTO es lo máximo que necesita.
Más información sobre cómo el diseño de beneficios de CQRS se puede encontrar aquí
Además, no se olvide de los beneficios no tangibles de CQRS
Si aún tienes dudas, quizás quieras leer esto
Actualmente usamos CQRS para proyectos de mediana complejidad y hemos encontrado que es muy adecuado. Comenzamos usando un código de arranque personalizado y ahora pasamos a usar Axon Framework para brindarnos algunos de los componentes de infraestructura.
Siéntete libre de enviarme un PM en caso de que quieras saber algo más específico.
Hay un problema fundamental del patrón de abastecimiento de eventos, es decir, es posible que los eventos en el Almacén de eventos ya no sean compatibles con los 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 su aplicación se vuelva más compleja, le resultará realmente doloroso hacerla compatible con versiones anteriores.
Sección de Reseñas y Valoraciones
Recuerda que tienes concesión de añadir una evaluación si diste con la respuesta.