Können Sie das Architekturmuster CQRS (Command-Query Responsibility Segregation) verwenden, um eine Site wie StackOverflow zu erstellen? Ich bin relativ neu in CQRS und DDD (Domain Driven Design) und erkunde das Muster und versuche, mit dem Muster vertraute Seiten zu modellieren. Während ich sehe, dass CQRS für eine Site wie StackOverflow für viele Aspekte nützlich ist, gibt es ein paar Bereiche, von denen ich nicht sicher bin, ob sie möglich sind (oder zumindest kann ich es nicht sofort herausfinden). Speziell:
Meine Sorge dreht sich wirklich um das Konzept des unmittelbaren Feedbacks, das SO bietet. Kann CQRS dies bieten? Wenn ja, wie würde dies geschehen? Gibt es gute Beispiele, die zeigen, wie man damit umgeht?
Wenn es hilft, ist meine Umgebung VS2010 / C # / SQL2008R2, aber ich bin offen für andere Optionen wie SQLite usw. Ich schaue auch auf NCQRS und LOKADs Framework, zusammen mit Mark Nijhofs Beispiel und plane das Herunterladen Greg Youngs Probe. Ich habe dort nicht viel anderes für CQRS Proben gefunden.
Danke!
Worüber Sie eigentlich sprechen, ist die "mögliche Konsistenz", über die zur gleichen Zeit wie CQRS gesprochen wird, aber Sie können beide Techniken unabhängig voneinander verwenden.
Am einfachsten ist es, das Modell, das die Benutzeroberfläche sofort verwendet, zu aktualisieren und diese Frage dem Benutzer zur weiteren Bearbeitung anzuzeigen. Die verschiedenen Arbeitsschritte, die ausgeführt werden müssen, damit die anderen Benutzer die Aktualisierung sehen können, können dann fortfahren, ohne die Benutzeroberfläche zu blockieren. Damit dies funktioniert, müssen Sie Ihren Befehl validieren, so dass er fast sicher ist, bevor er gesendet wird (wenn der Befehl während der Ausführung fehlschlägt, müssen Sie die Situation behandeln, z. B. eine Art Rückruf zum UI-Modell integrieren) .
Es ist auch wichtig zu bedenken, dass die "Eventualität" in der Regel so schnell ist, dass alles sofort erscheint, sogar für andere Benutzer.
Schauen wir uns die zwei Fragen an ...
Fragen stellen Wenn ich eine Frage erstelle, sehe ich sie sofort und kann sie bearbeiten. In CQRS gebe ich einen Befehl wie "AskQuestion" aus und es wird ein Ereignis namens "QuestionAsked" erstellt. Schließlich wird die Frage an den denormalisierten Datenspeicher weitergeleitet. Aber die Erfahrung von SO ist unmittelbar. Ist das mit CQRS möglich?
Dies kann leicht erreicht werden. Muss jeder Benutzer die Frage sofort sehen oder nur die Person, die es fragt? Wenn es 1-2 Sekunden dauert, bis es allen erscheint, würde es einen Unterschied machen? Meistens besteht in letztendlich konsistenten Systemen ein Unterschied zwischen dem Benutzer, der eine Anfrage sendet, und jedem anderen Benutzer.
Abstimmung Meine Stimmen werden sofort wiedergegeben. In CQRS würde ich mir vorstellen, dass diese Befehle / Ereignisse sich schließlich über den Ereignisbus zum Lesespeicher bewegen. Aber SO gibt mir die Informationen sofort.
Gibt SO es sofort? Versuchen wir ein anderes Beispiel, Facebook. Wenn Sie auf etwas klicken, wird dies sofort in Ihren Likes angezeigt? UI-Tricks wie das Hochziehen eines Daumens geben dir das Gefühl, dass es funktioniert. Ein anderes Beispiel, Amazon. Wenn Sie in den Warenkorb klicken, wird es sofort in Ihren Warenkorb gelegt? Visuelle Darstellungen wie "zum Warenkorb hinzugefügt" oder ein "Daumen hoch" lassen Sie als Benutzer sich fühlen wie es gemacht wurde.
Es gibt viele Tricks wie diese, die ein letztendlich konsistentes System zu einem vollständig konsistenten System machen können.
Als Nebenbemerkung denken viele Leute, dass diese Art von Dingen wegen der Skalierbarkeit gemacht werden (was manchmal der Fall ist). Häufiger werden sie für die Zuverlässigkeit getan. Die Frage wird, wenn XYZ nicht verfügbar ist. Möchten Sie seltsame zufällige lokale Fehler oder möchten Sie einen weit verbreiteten Ausfall riskieren? Eines der besten Beispiele, um hier zu sehen ist amazon für einen Kindle Kauf, es ist seltsam, dass sie Ihre Kreditkarte in 100ms verarbeiten können, während alle anderen dauert 3-5 Sekunden :) Was passiert, wenn ihre Kreditkarten-System ist nicht verfügbar ?
Wenn Sie eine Frage stellen, können Sie die Daten in der Benutzeroberfläche "fälschen". Es sieht so aus, als wäre es sofort für den Benutzer (Sie) aktualisiert worden, aber es wird einige Zeit dauern, bis die anderen Benutzer Ihre Frage sehen. Sie müssen dasselbe tun, um mit der Abstimmung umzugehen.
Wenn Sie sofortiges Feedback benötigen, können Sie andere Lösungen in Erwägung ziehen. Es gibt jedoch einige Tricks, mit denen Sie in einer CQRS-Lösung sofort Feedback geben können. Wenn Sie beispielsweise überprüfen müssen, ob ein Benutzername uniqe ist, können Sie die gelesenen Datenbanken abfragen, um herauszufinden, ob der Benutzername existiert. Wenn nicht, können Sie es verwenden. Wenn jedoch ein anderer Benutzer in der Zwischenzeit denselben Benutzernamen gewählt hat, erhalten Sie einen Konflikt auf der Befehlsseite. Sie müssen dies in Ihrem Domänenmodell behandeln und dem Benutzer beispielsweise einen generierten Benutzernamen geben und ihn per E-Mail senden. Er kann es später zu etwas anderem ändern.
Mit Fake oder Trick können Sie sich das Ereignis als "ausstehendes Ereignis" vorstellen, etwas, das in der Festschreib- / Veröffentlichungsphase wahrscheinlich erfolgreich ist, aber möglicherweise fehlschlagen könnte. Je mehr Validierungen Sie vor der ersten Übergabe an die Clients durchführen, desto wahrscheinlicher wird es. Wenn Sie sich also auf eine ausstehende Festschreibung verlassen möchten, planen Sie einen dickeren Client hinsichtlich der Validierung und der Einhaltung von Geschäftsregeln.
Man könnte dann dem Benutzer erlauben, die Daten (für weitere Modifikationen) weiter zu verwenden, indem er die Daten innerhalb der UI markiert oder taggt, wobei er sich auf "ausstehende Übertragung" verlässt. Es wäre ein Meta-Attribut des Objekts oder Attributs. Natürlich wird das Hinzufügen und Verwenden dieses Meta-Attributs die Komplexität erhöhen, aber abhängig von der Anwendung könnte dies ein notwendiger Anwendungsfall sein.
Clientseitige Befehlswarteschlangen / -historien könnten eine Möglichkeit sein, Situationen zu behandeln, in denen sich nachfolgende Ereignisse auf eine letztendlich fehlgeschlagene ausstehende Festschreibung stützten. Mit anderen Worten, alles, was auf eine ausstehende Festschreibung angewiesen ist, könnte Teil eines Verlaufs sein, der zusammengerollt werden konnte, während Korrekturen an der fehlgeschlagenen ausstehenden Festschreibung gespeichert wurden, abgerollt und erneut auf das geänderte und erneut übermittelte ausstehende Ereignis angewendet wurden, und nach der Benachrichtigung Das ausstehende Ereignis war erfolgreich beim Festschreiben, alle nachfolgenden clientseitigen Ereignisse begannen sich zu lösen, übermittelten das nächste Element in der Warteschlange und markierten es als das jetzt ausstehende Ereignis.
Tags und Links architecture cqrs