CQRS, missionsbasierte Benutzeroberfläche, Ereignisquellen ... ah

Ursprünglicher Autor: Greg Young
  • Übersetzung
Bemerkung von mir. Es war nicht einfach, die Terminologie zu wählen, daher bin ich bereit, die Übersetzung zu bearbeiten, um das Verständnis des Textes zu verbessern.

Viele irren sich darüber, was CQRS ist. Sie sehen CQRS als eine Architektur, obwohl dies nicht der Fall ist. CQRS ist eine einfache Vorlage mit vielen Architekturmerkmalen. CQRS ist keine ultimative Konsistenz, kein Ereignis oder Messaging, kein Modell zum Lesen und Schreiben und keine Verwendung von Ereignisquellen. Ich werde versuchen, in einigen Absätzen zu beschreiben, was CQRS ist, und dann überlegen, wie es sich auf andere Vorlagen bezieht.

Trennung von CQRS-Befehlen und -Abfragen

Wenn Sie mit CQRS arbeiten, müssen Sie verstehen, dass CQRS die Erstellung von zwei Objekten ist, die zuvor eins waren. Die Trennung basiert auf der Tatsache, dass Methoden Befehle oder Abfragen sind (Meyer verwendete dieselbe Definition in Befehls- und Abfragetrennung, ein Befehl ist eine Methode, die den Status ändert, und eine Abfrage ist eine Methode, die einen Wert zurückgibt).

Wenn die meisten von CQRS sprechen, meinen sie, sich dem Objekt zu nähern, das der Dienst der Anwendung ist. Betrachten Sie den folgenden Pseudo-Service-Code.

CustomerService

void MakeCustomerPreferred (CustomerId)
Customer GetCustomer (CustomerId)
CustomerSet GetCustomersWithName (Name)
CustomerSet GetPreferredCustomers ()
void ChangeCustomerLocale (CustomerId, NewLocale)
Leere CreateCustomer (Kunde)
Leere EditCustomerDetails (Kundendetails )

Anwendung CQRS dies zu zwei Dienste führen wird

CustomerWriteService

Leere MakeCustomerPreferred (CustomerId)
Leere ChangeCustomerLocale (CustomerId, NewLocale)
Leere CreateCustomer (Kunde)
Leere EditCustomerDetails (Kundendetails )

CustomerReadService

Kunden GetCustomer (CustomerId)
CustomerSet GetCustomersWithName ( Name)
CustomerSet GetPreferredCustomers ()

Das ist alles. Dies ist das Gesamtbild der CQRS-Vorlage. Nicht mehr ... Es scheint unterhaltsam, wenn wir es in dieser Form beschreiben, nicht wahr? Diese Trennung ermöglicht es, architektonisch Interessantes zu bringen. Und was sehr wichtig ist - es hilft dabei, den Prozess der geistigen Behinderung zu stoppen, da zwei dieselben Daten verwenden und außerdem dasselbe Datenmodell verwenden müssen.

Der größte Vorteil besteht darin, dass beim Arbeiten mit Befehlen und Abfragen verschiedene architektonische Eigenschaften erkannt werden. So können beispielsweise zwei Dienste auf unterschiedliche Weise platziert werden: Wir können einen Lesedienst auf 25 Servern und einen Schreibdienst auf zwei Servern hosten. Die Verarbeitung von Befehlen und Anforderungen erfolgt grundsätzlich asymmetrisch, eine symmetrische Skalierung dieser Dienste ist wenig sinnvoll.

Aufgabenbasierte Benutzeroberfläche Die aufgabenbasierte

Benutzeroberfläche unterscheidet sich erheblich von der auf CRUD basierenden Oberfläche. Darin verfolgen Sie, was der Benutzer tut, und fördern Teams, die seine Absichten vertreten. Ich möchte betonen, dass CQRS keine jobbasierte Schnittstelle erfordert. Sie können CQRS in einer CRUD-Anwendung anwenden (obwohl das Erstellen separater Modelle beispielsweise sehr viel schwieriger ist).

Aber es gibt eine Sache, die wirklich eine ähnliche Schnittstelle erfordert - dies ist ein Domänenmodell.

Die Anwendungsserviceschicht im Domänenmodell repräsentiert die Aufgaben, die das System ausführen kann. Dies sind nicht nur Prozesse wie das Kopieren von Daten in ein Domänenobjekt und das Speichern von Daten ... Vergessen Sie nicht das Verhalten mit dem Objekt. Bevor wir weitermachen, wollen wir sehen, was passiert, wenn wir es trotzdem tun.

In unserer gemeinsamen Sprache gäbe es keine anderen Verben als "Erstellen", "Löschen" und "Ändern". Und während es viele Domänen gibt, in denen die Sprache genau das ist, sollten Sie das Prinzip der Domänenmodelle nicht verwenden, um ein System zu erstellen.

Das Konzept einer solchen Schnittstelle soll nicht Teil von CQRS sein, und die Domäne kann ähnliche Befehle haben. Es muss den Absichten des Benutzers folgen, was sehr wichtig ist. Wurde dieses Update erzwungen oder nicht? Egal? Kommt darauf an, welche Frage Sie sich gestellt haben.

Fahren Sie mit der nächsten Vorlage fort, die in CQRS irreführend ist.

Quellen von Ereignissen.

Ich möchte klarstellen , dass ich mit diesem Begriff nicht alles meine, was in bliki geschrieben ist . Ich bezeichne das Speichern des aktuellen Status als eine Reihe von Ereignissen und setze den Status des Systems fort, indem ich diese Reihe von Ereignissen wiederhole ...

Auf der Befehlsseite der Gleichung kann das Speichern von Ereignissen eine gute Möglichkeit sein, um den aktuellen Status beizubehalten, da das Lesen nicht mehr Teil der Domäne ist. Der Wert erhöht sich, wenn Sie sich für zwei separate Modelle entscheiden (ein Modell zum Lesen und ein Modell zum Schreiben) und wenn Sie sie integrieren müssen, werden Sie dies höchstwahrscheinlich über Ereignisse tun. Warum nicht ein einziges Modell für das Staatsmanagement verwenden, da das Ereignis erhalten bleibt?

Messaging-Vorlage

Bei CQRS muss dieser Ansatz nicht verwendet werden. Wenn Sie jedoch Ihre Datenmodelle freigeben, werden Sie höchstwahrscheinlich Messaging zwischen ihnen verwenden, da in diesem Fall neue Opportunities angezeigt werden.

Schließlich bin ich zum letzten „Ansatz“ gekommen, obwohl ich ihn nicht gerne so bezeichne, da es sich in Wirklichkeit um ein Konzept handelt, das die Leute in ihre CQRS-Definitionen einfügen, was mit Messaging einhergeht ...

Endgültige Konsistenz

Das Prinzip der endgültigen Konsistenz wird auch ziemlich oft eingeführt zwischen den Diensten. Dies ist auf viele architektonische Impulse zurückzuführen. Der größte Vorteil ist jedoch, dass Sie die Skalierbarkeit und Verfügbarkeit erhöhen können. Wenn Sie sich an das CAP-Theorem erinnern, heißt es, dass die anderen beiden Eigenschaften verstärkt werden, wenn es keine Konsistenz gibt. Dies ist sehr gut für Modelle, wenn sie getrennt sind, aber dies ist keineswegs eine spezielle Eigenschaft von CQRS.

Jetzt können wir sehen, dass CQRS tatsächlich eine ziemlich einfache Vorlage ist. Alles, was sich um CQRS dreht, ist nicht nur CQRS, sondern auch die architektonischen Merkmale der Integration der beiden Dienste. Mit anderen Worten, das Interessanteste ist nicht die CQRS-Vorlage, sondern die Entscheidungen, die auf diesem Weg getroffen werden. Es gibt viele interessante Lösungen, die in dem System verwendet wurden, in dem sie beschlossen, CQRS zu verwenden ... aber dies ist nicht nur CQRS an sich.

Jetzt auch beliebt: