cqrs

Xendor

Xendor ist ein .NET -Kern -Framework, das verwendet werden kann, um ein einfaches und sauberes Design zu erstellen, indem einzelne Verantwortung und Trennung von Bedenken durchgesetzt werden. Die fortgeschrittenen Funktionen sind ideal für Domain Driven Design (DDD), Befehlsabfrage Responsibilty Segragation (CQRS) und Event Sourcing. Xendor hat auch Rabbitmq -Integrationen.

Was ist CQRs?

Die Verantwortung der Befehlsquerität ist ein Muster, das uns aufweist, Operationen zu trennen, die Daten von denen mutieren, die es abfragen. Es wird von CQS aus der Befehlsabfrage -Trennung (CQS) abgeleitet, dass es in einer Klasse nur zwei Arten von Methoden geben kann: diejenigen, die den Zustand mutieren und void zurückgeben, und diejenigen, die den Zustand zurückgeben, aber nicht ändern.

CQRS ist ein Muster, auf das Sie anwenden? Die Innenseiten? Ihr Service/Ihre Anwendung und Sie können ihn nur auf den Teil Ihres Dienstes beantragen.

Das sind keine CQRs

Es ist keine eventuelle Konsistenz

Es ist keine Veranstaltung

Es ist keine Nachrichten

Es ist keine getrennten Modelle zum Lesen und Schreiben von getrennten

Auch wird Event Sourcing nicht verwendet.

CQRS Pros & Cons & Cons

Profis:

• Bessere Leistung und Skalierbarkeit Ihres Systems.
• Bessere gleichzeitige Zugang zur Handhabung.
• bessere Teamskalierbarkeit.
• Weniger komplexes Domänenmodell und einfaches Abfragemodell.

Nachteile:

• Lesen und Schreibmodelle müssen synchronisiert werden.
• Wartungs- und Verwaltungskosten Wenn Sie zwei verschiedene Motoren für das Lesen und für die Schreibseite auswählen.
• Eine eventuelle Konsistenz ist nicht immer zulässig.

Was ist Event Sourcing?

Verwenden Sie anstatt nur den aktuellen Status der Daten in einer Domäne zu speichern, um die vollständige Reihe von Aktionen, die auf diesen Daten ergriffen wurden, aufzuzeichnen. Der Laden fungiert als Aufzeichnungssystem und kann verwendet werden, um die Domänenobjekte zu materialisieren. Dies kann die Aufgaben in komplexen Domänen vereinfachen, indem die Notwendigkeit vermieden wird, das Datenmodell und die Geschäftsdomäne zu synchronisieren und gleichzeitig die Leistung, Skalierbarkeit und Reaktionsfähigkeit zu verbessern. Es kann auch Konsistenz für Transaktionsdaten bieten und vollständige Prüfungsspuren und Geschichte beibehalten, die kompensierende Aktionen ermöglichen können.

In welchen Systemen lohnt es sich, Event Sourcing zu verwenden?

• Ihr System hat viele Verhaltensweisen, die kein gewöhnlicher Crud sind.
• Das Erstellen historischer Objektzustände ist sehr wichtig
• Geschäftsbenutzer sehen Vorteile, in der vollständigen Geschichte für Statistiken, maschinelles Lernen oder andere Zwecke zu verfügen.
• Ihre Domain wird am besten durch Ereignisse beschrieben (z. B. eine Bewerbung, um ein Assistance -Fahrzeugaktivitäten zu verfolgen).

Ereignisbeschaffung Vor- und Nachteile

Profis:

• Das nur Modell anhängen ist hervorragend für Leistung, Skalierbarkeit
• Keine Deadlocks
• Ereignisse (Fakten) werden vom Geschäftsexperten gut verstanden, einige Domains sind von Natur aus Event Sozius: Rechnungswesen, Gesundheitswesen, Handel
• Prüfpfad kostenlos
• Wir können zu jedem Zeitpunkt Objektzustand erhalten
• leicht zu testen und zu debuggen
• Datenmodell entkoppelt aus dem Domänenmodell
• Keine Impedanzfehlanpassung (Objektmodell vs Datenmodell)
• Flexibilität? Viele verschiedene Domänenmodelle können aus demselben Ereignisstrom konstruiert werden
• Wir können dieses Modell mit Umkehrereignissen und rückwirkenden Ereignissen verwenden
• Keine Orms mehr? Dank der Tatsache, dass unser Objekt aus Ereignissen erstellt wurde, müssen wir es nicht in einer relationalen Datenbank widerspiegeln

Nachteile:

• Nicht natürliche Möglichkeit für Entwickler, den Zustand zu verwalten und Aggregate zu konstruieren, braucht Zeit, um sich daran zu gewöhnen
• Das Abfragen über ein Aggregat ist etwas schwieriger (Sie müssen Projektionen für jede Art von Abfrage konstruieren, die Sie dem System hinzufügen möchten).
• Ereignisschema -Änderungen sind viel schwieriger als im Fall eines relationalen Modells (Mangel an Standard -Migrationsinstrumenten für Standardschema)
• Sie müssen von Anfang an die Handhabung der Versioning in Betracht ziehen.

Ereignisbeschaffung - Projektionen

Die Projektion ist ein wichtiges Konzept beim Aufbau von ereignisorientierten Systemen. Gleichzeitig ist es extrem einfach.

Bei der Projektion geht es darum, den aktuellen Zustand aus dem Ereignisstrom abzuleiten.

Betrachten Sie beispielsweise eine Situation, in der ein Ereignisstrom von einem Server an alle Abonnenten veröffentlicht wird. Diese Ereignisse beziehen sich auf Benutzerregistrierungen und sehen aus wie:

UserAddedToAccount

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "name" : " Alejandro " ,
 "lastName" : " Moline "
}

UserVerifiedMail

{
 "userId" : 55 ,
 "email" : " [email protected] "
}

UserUpdated

{
 "userId" : 55 ,
 "lastName" : " Molines "
}

Wir können einen Abonnenten an Stream dieser Ereignisse anhängen, um diesen Stream in ein persistierendes Lesemodell zu projizieren, das zur Bereitstellung von Benutzerdetails in einer Web -Benutzeroberfläche verwendet wird. Das endgültige Lesemodell könnte aussehen:

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "email" : " [email protected] " ,
 "name" : " Alejandro " ,
 "lastName" : " Molines "
}

CQRs mit Event Sourcing (CQRS-ES)

Gib einen Stern!

Wenn Sie dieses Projekt mögen oder verwenden, geben Sie ihm bitte einen Stern. Danke!

Ich habe ein Problem gefunden oder habe eine Änderungsanfrage

Fühlen Sie sich frei, ein Problem auf Github zu erstellen. Beiträge, Zuganfragen sind mehr als willkommen!

Xendor ist Copyright © 2019 Alejandro Molines und andere Mitwirkende im Rahmen der MIT -Lizenz.