CQRS-ES

Escrituras eficientes y no bloqueantes
Cada crítico state el cambio se registra en el lado de escritura como domain events, de manera que solo se añadan. Dado que no es necesario persistir y mantener un actual separado state, no hay necesidad de actualización en el lugar y no es necesario implementar soluciones de bloqueo optimista, eliminando el riesgo de contención.

Consultas eficientes del lado de lectura con modelos de vista complejos, sin afectar el lado de comando
Consultas complejas para fines de búsqueda y análisis se ejecutan en el lado de lectura separado. Aceptando la realidad de que siempre habrá un elemento de retraso al leer/recuperar datos y eventual La consistencia permite desacoplar los modelos de lectura y escritura. Se crean una variedad de modelos de lectura y proyecciones complejas al obtener los datos del lado de escritura como parte de la proyección/sincronización, sin afectar el procesamiento general de pagos.

Escalado independiente de equipos y uso de tecnología
La separación del lado de lectura y del lado de escritura también permite una mayor desacoplación de equipos y tecnologías, proporcionando oportunidades para escalar diferentes equipos y aplicar tecnologías especializadas con el fin de mejorar la eficiencia de los equipos y de las soluciones de lectura y escritura. Es posible aplicar opciones tecnológicas y optimizaciones que pueden diferir entre el lado de lectura y el lado de escritura.

No es necesario mantener un historial de ejecución separado
**Domain events son hechos inmutables que representan el cambio en state. Al empoderar domain events ser la parte crítica de la solución y construir la aplicación state basado en ellos también ofrece la ventaja de mantener un historial de ejecución crítico para el negocio como parte del procesamiento de pagos, no como una reflexión posterior.

Consistente state gestión
Domain events convertirse en la única fuente de verdad, eliminando el riesgo de publicar un domain event a la exterior pero sin actualizar el state consistentemente.

Mejora en la autoconstrucción y solución de problemas
En caso de fallos temporales, grabados domain events puede ser reproducido nuevamente para recuperar la aplicación state para permitir la autorreparación, la depuración o la resolución de problemas.

El archivado es mucho más fácil en datos inmutables
Sin duda, es mucho más seguro archivar inmutable.domain events a un almacenamiento más lento.

El modelo de objeto no tiene que ser el mismo que el modelo de datos
CQRS le guía naturalmente a modelar su dominio con las preocupaciones adecuadas desde el principio. Los comandos se modelan para contener información concisa que es suficiente para hacer decision sobre cómo manejar el comando. Esto permite que el modelo esté más enfocado y no se llene de preocupaciones que no sirven al propósito.

Adopte eventual consistencia
Con CQRS, habrá un retraso natural entre las escrituras y las lecturas, ya que las actualizaciones de datos pueden no estar disponibles de inmediato en el lado de lectura. Comprenda los límites aceptables y aplique optimizaciones para reducir la latencia. Es mejor comenzar cuestionando las razones detrás de los requisitos para una consistencia fuerte. Puede volverse evidente que todo ese esfuerzo y costo por una consistencia fuerte puede no proporcionarle el beneficio comercial deseado; incluso puede degradar la aplicación, resultando ser aún más costoso.

Curva de aprendizaje pronunciada
Al igual que con cualquier otra cosa, hay una curva de aprendizaje que requiere un cambio del pensamiento de diseño tradicional. Sin embargo, el patrón no es nuevo y existen muchas implementaciones diferentes con ejemplos y artículos.

Compatibilidad hacia atrás
**En event sourcing, en realidad es más fácil introducir un nuevo state ya que realmente no impactará el modelo general. Sin embargo, con el tiempo, puede que necesite aplicar más cambios disruptivos, como cambios obligatorios en un event estructura. Un buen enfoque es ser flexible en lo que usted acepta del exterior y estricto al exponer datos al exterior. Esto puede permitir la introducción de adaptadores cuando sea necesario. Realice una instantánea antes de introducir cambios disruptivos y difunda un cambio importante.event también son estrategias útiles.

Incremento en el volumen de datos
Naturalmente, habrá más datos que la aplicación estará persistiendo. Esto se debe principalmente a que la pista de auditoría de 'cómo llegamos allí' es ahora la parte crítica del dominio. El archivado ya no es tan problemático, ya que se trata de un registro de solo anexar. Eliminar el events Después de la transmisión y la captura de instantáneas, también podría ayudar con las preocupaciones sobre el volumen de datos.

Reconstrucción state puede ser costoso
A medida que el número de events para representar el state cambios en un objeto de dominio crecen, puede volverse ineficiente rehidratar todos los events para que el objeto construya su actual state. La creación de instantáneas es útil y puede aplicarse a la domain events después de un cambio importante. Esto reduciría el número de events para ser rehidratado y mejorar el rendimiento general. Otra opción podría ser mantener el objeto de dominio en memoria, quizás para introducir un distribuido cache. Este es un enfoque arriesgado y debe asegurarse cache se actualiza de manera consistente a medida que el domain events son persistidos.

Desafíos en la verificación de duplicados
**La verificación de duplicados se utiliza a menudo como una crítica para event sourcing. Como no hay un tipo de actualización en el lugar data management, puede ser más desafiante detectar entidades duplicadas. Nuevamente, existen diversas estrategias para superar eso. Una estrategia es permitir duplicados pero implementar un proceso riguroso posterior que maneje los datos duplicados. Sin embargo, esto no funcionará para instant los pagos, ya que el movimiento de dinero es muy crítico y permitir pagos duplicados sería demasiado arriesgado. Otra estrategia podría ser utilizar el identificador único para el pago como clave primaria para events, no permitiendo duplicados events para el mismo ID de pago. Sin embargo, dado que el ID de pago es a menudo una combinación de campos obligatorios y opcionales, podría ser un desafío implementar un identificador único de este tipo. Una mejor estrategia es mantener un temporal cache de objetos de pagos cercanos a la aplicación y nuevos comandos de ejecución de pagos podrían ser verificados contra el cached los pagos y se rechazarán si se detecta duplicación.