Por lo que he leído, los diseños CQRS implican comandos asincrónicos donde los comandos se ponen en una cola. El usuario asume que todo está bien y las encuestas de UI o mediante un temporizador obtienen algo de retroalimentación si todo funcionó o no.¿Los comandos de Do deben ser asincrónicos en CQRS?
¿Cómo funcionaría esto si tuviera una IU donde estoy arrastrando carpetas en un árbol? Podría hacer que un usuario borre una carpeta mientras que otra le arrastra una carpeta (para convertirla en una subcarpeta).
De modo que desde la IU pude ver que se ha producido el arrastre y luego comprobar en algún temporizador si mi modelo de lectura ha sido actualizado (es decir, verificar la carpeta principal de la carpeta arrastrada y si está configurada correctamente) sé que funcionó).
Si el usuario ha realizado una serie de operaciones de arrastre, tendría que mantener una lista de estas operaciones en la interfaz de usuario y verificar la lectura de almacenamiento (eliminando los comandos exitosos de la lista).
Quizás haya mejores formas de hacerlo.
Simplemente parece mucho trabajo en la interfaz de usuario y más propenso a errores, mientras que si solo ejecuto un comando sincrónico y todo está bien, entonces paso a la siguiente operación.
Gracias por la respuesta. –
Veo esto más como un esfuerzo para informar a los usuarios lo antes posible si sus acciones tienen éxito o no. En mi opinión, desde el punto de vista de la facilidad de uso de la interfaz de usuario es malo permitir a los usuarios arrastrar carpetas alegremente para "llamar al servidor" varios segundos después y descubrir que todas estas acciones fueron rechazadas. Creo que el usuario debe estar informado. inmediatamente. El mismo caso para los problemas con el guardado de datos (¡piense en la validación!), Y la mayoría si no todas las demás condiciones de error. – Dav
"Esforzarse por informar a los usuarios lo antes posible si sus acciones tienen éxito o no" no es un requisito universal que todo sistema debe cumplir. Si el estado actual de la aplicación es crítico para determinar las acciones disponibles para el usuario, entonces los comandos asincrónicos probablemente no sean la mejor decisión de diseño, pero eso no significa que el uso de comandos sincrónicos sea una bala mágica que evitará que el estado cambie. * entre comandos emitidos por un solo usuario *. – arootbeer