Zeige Änderungen anzeigen, wenn CQRS & DDD mit Domain Events & ServiceBus mit

Question

Ich bin ein wenig über den Fluss in einem System verwechselt Ereignisse mit Domain des gelesenen Modell zu bauen. Insbesondere, wie wir mit der Tatsache umgehen, dass die Benutzerdaten erwartet (und seine Ansicht) zu ändern, wenn sie einen Befehl abgeschlossen hat, aber aufgrund unserer Systemarchitektur (nicht-blockierende Aufrufe Ereignisse zu veröffentlichen) die aktuellen Datenbank nicht vor dem ändern könnte Seite neu geladen wird?

Ich hoffe, dass das Design eines unserer Systeme mehr inline mit CQRS mit Veranstaltungen und einen Service-Bus zu bewegen.

Lassen Sie uns sagen, mein Flow geht als solche:

1. Der Benutzer klickt auf Schaltfläche Ansicht Aufgabe auszuführen Zahlungsmethode von ihrem Konto zu entfernen.

2. Controller ruft PaymentMethodRemovalService, vorbei es accountId & paymentMethodId.

3. Controller verwendet AccountRepository Konto abrufen und ruft account.RemovePaymentMethod (id)

4. Account bestätigt, dass Betrieb auftreten können und veröffentlicht Ereignis PaymentMethodRemovedMessage (accountId, paymentMethodId)

5. Da die Ereignisveröffentlichung asynchron ist, wir von Service und Rückkehr Ansicht zurückkehren müssen nun von der Steuerung - aber unsere eigentlichen Daten noch nicht aktualisiert

6. Ein Handler, iHandle , hört das Ereignis und entfernt die aktuelle Zeile aus der DB

Also, was ist ein Kerl zu tun?

Ich könnte einfach sagen, das div entfernen, die die Zahlungsmethode anzeigte. Dies kann in einem AJAX-Szenario arbeiten, aber was ist, wenn ich mit Post-Redirect-Get Nicht-JavaScript-Clients zu unterstützen. Dann werde ich meine Get und Lesen der Daten aus der Abfrage-Seite der Dinge feuern, möglicherweise bevor es aktualisiert wird.

Do zeige ich nur eine Benachrichtigung ihre Anfrage sagen die Zahlungsmethode entfernen vorgelegt worden ist? (Was nicht zu freundlich scheint, macht Sinn für einen Auftrag einreichen, aber nicht für, sagen wir, eine Adresse zu ändern).

Gibt es eine Möglichkeit der Umsetzung Änderungen als entkoppelte asynchrone Ereignisse in Einklang zu bringen und die Benutzerdaten zeigt, die ihre Stromänderung reflektiert?

EDIT: Meine Frage an CQRS ziemlich ähnlich ist, synching DDD Datenbank Berichterstattung I zu sagen haben, angesichts der Antwort gibt und auch hier erwähnt, hat ein bisschen von einem Geruch zu ihm - die Benutzeroberfläche Gerangel ein Update zu zeigen, dass der Band ist aus mit der DB zu lesen, so zu sprechen. Ich war ein wenig Reiniger für etwas zu hoffen.

Answer 1

Wenn Sie in das Request / Response-Modell gesperrt werden, könnten Sie eine Correlated Request / Response-Muster annehmen. Für genauere Angaben, überprüfen Sie die Async Seiten Probe in dem NSB-Download aus. Dies zeigt, Request / Response in einer ASP.NET-Einstellung. Es gibt einige ASP.NET MVC Beispiele gibt, wenn das ist Ihre Sache.

Wenn Sie die asynchrone Verarbeitung einführen, akzeptieren Sie, dass die Daten abgestanden sein wird. Man kann argumentieren, dass, sobald Sie die DB die Daten abfragen schon alt ist (Netzwerk-Latenz, die Rendering-Zeit usw.). Da die Daten bereits alt ist, müssen wir uns fragen, wie alt ist gut genug?

Eine weitere Sache zu prüfen ist, dass Ihre Verarbeitung etwas nicht in Ordnung ist. Schritt 3 soll den Befehl Validieren sein, bevor sie an den Server zu senden und dann die Schritte 3, 4 kommen würde, nach dem 6. Die Datenbank nur dann aktualisiert werden, wenn der Befehl gültig ist und das Ereignis sollte nur veröffentlicht werden, wenn die Datenbank erfolgreich aktualisiert wird.

Answer 2

Dieses Problem wird als 'Eventual Consistency'. Es gibt klare Möglichkeiten, es zu nähern. Der erste Punkt ist, dass jedes System Eventual Consistency hat, ob sie asynchrone Ereignisse verwenden oder nicht. Es ist nur so, dass Sie es machen entschieden haben, explizit, während die meisten anderen Systeme nur die Benutzer warten lassen, bis die Aktualisierung abgeschlossen ist. Beide Ansätze sind gültig, solange sie nicht explizit ausgewählt werden.

Vor einer Weile ich einen Blog-Post zu diesem Thema geschrieben, die Sie nützlich finden können. Sie können es hier finden: 4 Möglichkeiten, Eventual to Handle Konsistenz auf der Benutzeroberfläche

Hier ist eine kurze Version:

Option 1 - Verwenden Sie ein Bestätigungsfenster. Wenn Sie eine Bank App auf Ihrem Telefon verwenden haben Sie wahrscheinlich diese in Aktion gesehen. Bringen Sie etwas Geld und am Ende des Prozesses, werden Sie zu einer Bestätigung Bildschirm genommen, bevor sie auf Ihre Konten zurückgenommen. Dies gibt die Systemzeit auf dem Laufenden, um wieder nach oben.

Option 2 - Fake it. Wenn der Betrieb der Benutzer sehr wahrscheinlich versucht, ist erfolgreich zu sein, dann ist es fälschen kann ein legitimer Ansatz. Dies wird häufig verwendet, wenn Kauf von Tickets, die in der hohen Nachfrage sind. Ihre Transaktion durchlaufen kann, aber später die Firma entdeckt Ihre Tickets bereits verkauft hatten Millisekunden vor. Der Vorteil für das Unternehmen ist, dass sie den Verkauf haben, anstatt zu riskieren, beiden Kunden zu verlieren. Solange das System sorgfältig gebaut wird diese Situation sollte nur selten auftreten und daher kein Problem insgesamt sein.

Sie können auch Korrelation IDs verwenden, damit Sie Erfolg oder Misserfolg von Operationen abonnieren.

Wie auch immer, die Hoffnung, dass einige zum Nachdenken bietet.