Muestra los cambios en Vista cuando se utiliza CQRS y DDD con el dominio de Eventos y ServiceBus

Question

Estoy un poco confundido sobre el flujo en un sistema que utiliza los eventos de dominio para construir el modelo de lectura. En particular, ¿cómo lidiar con el hecho de que el usuario espera de datos (y su punto de vista) para cambiar al completar una orden, pero debido a nuestra arquitectura de sistema (llamadas sin bloqueo para publicar eventos) de la base de datos real podría no cambiar antes de la se vuelve a cargar la página?

espero para mover el diseño de uno de nuestros sistemas más en línea con CQRS utilizando eventos y un bus de servicio.

Digamos que mi flujo se dirige como tal:

1. El usuario hace clic en el botón de Vista para realizar tareas de eliminación de Pago de su cuenta.

2. Controlador llama PaymentMethodRemovalService, pasándole ACCOUNTID y paymentMethodId.

3. Controlador utiliza AccountRepository para recuperar la cuenta y llama account.RemovePaymentMethod (id)

4. Cuenta valida que la operación puede ocurrir y publica evento PaymentMethodRemovedMessage (ID de cuenta, paymentMethodId)

5. Debido a la publicación de sucesos es asíncrona, ahora tenemos que volver de servicio y de retorno vista desde el controlador! - pero nuestros datos reales no se actualiza sin embargo,

6. Un manipulador, iHandle , escucha el evento y elimina la fila real de la DB

Entonces, ¿qué debe hacer un hombre?

Me podría simplemente decir, quitar el div que estaba mostrando la forma de pago. Esto puede funcionar en un escenario de AJAX, pero lo que si estoy usando Post-redirección-Get para apoyar a clientes que no son de JavaScript. Entonces estará disparando mi Get y la lectura de los datos desde el lado de consulta de las cosas, posiblemente antes de que se pone al día.

No acabo de mostrar una notificación diciendo que su solicitud de eliminar la forma de pago se ha presentado? (Que no parece amigable, que tiene sentido para enviar un pedido, pero no para, por ejemplo, cambiar una dirección).

¿Hay una manera de reconciliar la implementación de cambios como eventos asíncronos desacoplados y mostrando los datos de usuario que refleja su cambio actual?

EDIT: Mi pregunta es bastante similar al , DDD sincronizando la presentación de informes de base de datos que tiene que decir, la respuesta dada allí y también aludido aquí, tiene un poco de olor a ella - wrangling la interfaz de usuario para mostrar una actualización que está fuera de la banda con el DB leen, por así decirlo. Me esperaba algo un poco más limpio.

Answer 1

Si está bloqueado en el modelo de solicitud / respuesta que podría adoptar un modelo de petición / respuesta correlacionada. Para obtener detalles específicos, echa un vistazo a la muestra Páginas asíncronas en la descarga NSB. Esto demuestra petición / respuesta en un entorno ASP.NET. Hay algunos ejemplos ASP.NET MVC por ahí si eso es lo que le gusta.

Cuando se introduce el procesamiento asincrónico usted está aceptando que los datos será rancio. Se puede argumentar que el momento se consulta la base de datos los datos ya es vieja (latencia de la red, el tiempo de renderizado, etc.). Dado que los datos ya es viejo, hay que preguntarse qué edad es lo suficientemente bueno?

Una cosa más a tener en cuenta es que su procesamiento es un poco fuera de orden. Paso 3 debe ser la validación de la orden antes de enviarla al servidor y luego los pasos 3, 4 vendría después de 6. La base de datos sólo debe actualizarse si el comando es válido y el evento sólo debe ser publicado si la base de datos se actualiza correctamente.

Answer 2

Este problema se conoce como 'La consistencia eventual'. Hay formas claras de acercarse a él. El primer punto a destacar es que cada sistema tiene consistencia eventual si están utilizando eventos asincrónicos o no. Es sólo que ha optado por hacerlo explícito, mientras que la mayoría de los otros sistemas sólo hacen que la espera del usuario hasta que se complete la actualización. Ambos enfoques son válidos, siempre y cuando se eligen de forma explícita.

Hace un tiempo escribí un post sobre este tema que le puede ser útil. Lo puedes encontrar aquí: 4 maneras de manejar eventual la consistencia en la interfaz de usuario

Esta es una versión corta:

Opción 1 - Utilizar una pantalla de confirmación. Si utiliza una aplicación de banca en su teléfono usted probablemente ha visto esto en acción. Transferir algo de dinero y al final del proceso, se le lleva a una pantalla de confirmación antes de ser llevado de vuelta a sus cuentas. Esto le da tiempo al sistema para volver al día.

Opción 2 - fingir. Si es altamente probable que tenga éxito la operación, el usuario está intentando, a continuación, fingiendo puede ser un enfoque legítimo. Esto se utiliza a menudo en la compra de billetes que están en alta demanda. Su operación puede pasar, pero más tarde los descubridores de la empresa pasaje ya se habían vendido milisegundos antes. El beneficio para la empresa es que tienen la venta en lugar de correr el riesgo de perder los clientes. Siempre y cuando el sistema está construido cuidadosamente esta situación debe ocurrir raramente y por lo tanto no es un problema global.

También puede utilizar el id de correlación para permitir que se suscriba al éxito o al fracaso de las operaciones.

De todos modos, la esperanza de que ofrece algunos elementos de reflexión.