CQRS – das einzige Video, das Du brauchst // deutsch

CQRS – sicherlich bist Du diesem Akronym bereits begegnet, insbesondere wenn Du Dich auch für Event-Sourcing interessierst. Doch was ist das, CQRS? Was ist die Idee dahinter? Wofür ist es gut? Welchen Zweck hat es? Und wie funktioniert es?

Golo Roden, Gründer und CTO der the native web GmbH, beantwortet Dir in diesem Video all diese Fragen und noch vieles mehr rund um CQRS. Und am Ende wirst Du nicht nur CQRS verstanden haben, sondern auch den Zusammenhang zwischen CQRS und Event-Sourcing kennen, und verstehen, warum die beiden Konzepte einander so gut ergänzen.

Planst Du mit Deinem Team ein neues Softwareprojekt? Wir beraten Euch bei der Konzeption, Architektur und Entwicklung. Gemeinsam mit Euch stellen wir Leitplanken und Wegweiser auf und sorgen für eine gemeinsame Sprache zwischen Fachlichkeit und Technologie – damit Eure Softwareentwicklung von Anfang an den richtigen Kurs einschlägt und nachhaltige Erfolge erzielt. Interesse? Dann melde Dich gerne bei uns:

────────────────────

Willst Du wissen, welche Videos es noch von uns gibt oder suchst Du eines zu einem bestimmten Thema? Hier findest Du die perfekte Übersicht über alle unsere Videos:

────────────────────

Möchtest Du demnächst den Job wechseln, hast aber Angst vor den technischen Fragen im Bewerbungsgespräch? Wir können Dir helfen! Werde Mitglied in unserem Coding-Circle und erhalte jede Woche exklusive Videos:

────────────────────

Hast Du Fragen zu diesem Video oder willst Du Dich mit Gleichgesinnten aus der Community austauschen? Dann komm auf unseren Discord-Server:

────────────────────

00:00 – 50.000 Abonnenten 🎉
00:35 – Einleitung
01:36 – CQRS vs Event-Sourcing
03:12 – Was ist CQRS?
04:40 – Was das Entwurfsmuster nicht sagt
05:13 – Warum ist CQRS relevant?
06:03 – Die 5. Normalform …
06:46 – … und ihre Nachteile
07:19 – Die 1. Normalform …
07:51 – … und ihre Nachteile
08:15 – Ein schlechter Kompromiss
08:53 – Was Normalformen mit CQRS zu tun haben
09:43 – Ein anschauliches Beispiel
11:27 – Fragen über Fragen
11:54 – Die Events als Single-Source of Truth
12:39 – Das perfekte Datenmodell zum Lesen
13:40 – Synchronisation zwischen Schreiben und Lesen
14:48 – Antworten auf unbekannte Fragen
15:33 – Relational, NoSQL & Co. – was wann?
17:02 – Auf Persistenz verzichten
17:48 – Ein Fundament für ein Data-Mesh
18:54 – Zugriffsrechte implementieren
19:34 – Zielgerichtetes Skalieren
20:42 – Herausforderungen von CQRS
21:32 – Eventual-Consistency
22:07 – Fachliche vs technische Fragen
23:23 – Ein Geldautomat als Beispiel
24:58 – Zu kompliziert?

────────────────────

[xykflo]

Ich bin immer wieder beeindruckt über deine Herleitung eines Themas. Es ist eine seltene Fähigkeit von einer Person, welche thematisch sehr tiefes Wissen besitzt, dies auf solch anschauliche Art und Weise zu erklären. Danke dafür.

[cosmochaosmaker]

Danke für die grandiose Umsetzung eines Videos zu diesem Entwurfsmuster. 👍

[marcusreinicke]

Danke Dir Golo für die hervorragende Erklärung. Das gehört mit zum Besten Veranschaulichungen, die ich bisher gehört habe

[yt]

Danke für das sehr informative Video. Hinter einem Begriff der eher an Browser Security erinnert, steckt ein gut durchdachtes Konzept, welches die Schere zwischen Schreib- und Lesezugriffen auf Datenbanken schließt.
Und Gratulation zu den 50.000 ABOs, wobei ich hier noch sehr viel Potential nach oben sehe. Aber vielleicht gibt die Nische doch nicht mehr her. Wir werden sehen was die Zukunft bringt.

Ich wünsche dir eine schöne und erfolgreiche Woche!

[marinaegner]

Danke fur das tolle Video! 😊
Obwohl ich es nicht anders gewöhnt bin, bin ich mal wieder erstaunt, wie anschaulich du die Sache erklärst.
Mich wurde ebenfalls ein Followup zur Validierung mit dem Saga Pattern interessieren.

[daspie]

Tolles konzept. Ich finde es lustig, dass ich genau das intuitiv von 10 Jahren als Uniprojekt umgesetzt habe.
Was mir dabei im Video leider noch zu kurz kam: Jeder Schreibprozess bzw. jede View benötigt dabei drei Vorgänge/Prozesse/Routinen, die berücksichtigt werden müssen:
* Einmal natürlich das Hinzufügen der History
* Dann ein Update der Status-Datenbank
* Dann eine recovery-Routine, die aus der History den Status berechnen kann.

Jeder Status benötigt also wenigstens diese 3 Routinen, damit der beschriebene Prozess funktioniert. Das klingt relativ aufwändig, kann sich aber definitiv lohnen.

[xlicepro]

Dein Kanal ist einfach eine der Besten Quellen zum Thema Event-Driven Architecture. So prägnant habe ich das noch nie erklärt bekommen!

Zum Video: Viel Gehirnschmalz steckt letztlich doch noch im Implementierungsdetail und da verliere ich mich oft noch.
Meinst du es macht Sinn für die Volltextsuche ein CDC Tool zu verwenden, um die Daten automatisch von der Read DB (Postgres) zu Elasticsearch zu syncen?

[saschab]

Danke, dass war wieder mal ein Augenöffner😊
Ich werde mich auf jeden Fall noch weiter mit dem Thema befassen. 👍

[anion]

Mal wieder ein sehr interessantes Video! Also ich sehe das zwar prinzipiell auch so, dass der Fachbereich z. B. entscheiden muss, welche Art von Konsistenz er haben will. Und in einer idealen Welt ist das sicherlich auch so, aber... Wenn man dem Fachbereich diese Frage stellt, bekommt man oft leider nur schiefe Blicke... ("Was ist Konsistenz? Ihr müsst das doch wissen, ihr seid die Techniker.") Bei dem Beispiel mit dem Bankautomat mag man die möglichen Optionen noch anhand der jeweiligen Folgen gut erklären können. Aber wenn man weniger anschauliche Usescases hat, wird es oftmals schwer, und dann trifft (meiner Erfahrung nach) eben doch oft das dev-Team die Entscheidung.

[Luca-mit-ca]

Das Video hat einen besseren Titel verdient. Ich habe es nur angeklickt weil ich noch nie von euch enttäuscht wurde obwohl ich es erst vermieden habe, denn ich konnte mir unter CQRS einfach nichts vorstellen. Wie wäre etwas wie: "CQRS - Der (blitzschnelle) Tod der 3. Normalform"

[jurgengoocon]

Das war wieder einmal ein super gemachtes Video, vielen Dank!, TOLL erklärt.
Du hattest erwähnt, dass man von verteilten Transaktionen besser die Finger lassen sollte.
Das habe ich mittlerweile ebenfalls verinnerlicht. Ich denke, dass im Umfeld Cloud, verteilten Services und
Microservices usw. verteilte Transaktionen heutzutage überhaupt nicht mehr in Frage kommen!
Aber mich würde interessieren, ob ihr Erfahrungen mit dem SAGA-Pattern gemacht habt,
wo es eher um Stornierungsmechanismen geht.
Über ein Video von euch zu diesem Thema (auch mit einer Betrachtung Choreography vs. Orchestration)
würde ich mich sehr freuen.

[DPabst-ewbu]

Danke für den verdammt guten Beitrag.

In Kliniken werden zwischen verschiedenen Systemen oft Patientendaten auf Basis HL7 übertragen. Verzögerungen bestehen hier zwischen den Systemen.Allerdings kommt langsam ein Wandel zu besseren Lösungen.

[pantarheipictures]

Danke euch! Ihr produziert einfach coolen Content❤

[Kurt-pt]

Wie immer, eine sehr coole Erklärung des Themas !!

Zu CQRS und Event Sourcing hätte ich zwei Fragen:

1.) Das Thema ist ja schon ein paar Jahre alt. Kommt das gerade erst in Mode, oder wird das "überall" eingesetzt und ich habe das bisher nur nicht mitbekommen?
2.) Was ist mit der OS Version von Wolkenkit passiert? Ich wollte mich mit den Themen CQRS und Event Sourcing beschäftigen, kann die OS Version von Wolkenkit aber leider nirgends mehr finden.

[Mokelet]

Zunächst einmal vielen Dank für das informative Video :-). Was sich in meinem Kopf noch als größeres Problem darstellt, ist die Validierung, wenn ein Command über die API eingeht und ich CQRS und Event-Sourcing betreibe. Nutze ich bei der Validierung dann die Events und baue mir mein Domainmodell zusammen, um anschließend zu validieren? Falls ja: Was mache ich dann, wenn meine Entscheidung von vielen Entitäten abhängig ist? Muss ich diese dann alle aus der Datenbank laden und zusammensetzen? Für das Buchbeispiel „Ich möchte ein Buch ausleihen“ muss ich natürlich nur das eine Buch laden um zu schauen, ob es aktuell ausgeliehen ist. Aber was würde ich tun, wenn die Bibliothek beispielsweise die Bedingung hat, dass mindestens 100 Bücher (egal welches) immer im Bestand sein sollen (Ich weiß, blödes Beispiel, aber mir fällt aktuell kein Gutes ein ^^).

[sennlich]

Und wieder wird etwas schon vorhandenes neu interpretiert und mit neuen Schlagworten verkauft.
Und ewig grüsst das Murmeltier.
Viel Erfolg damit.

[kngarthur]

Ich frage mich, ob es für das Speichern der Events überhaupt eine DB benötigt, die ja eine gewisse Struktur benötigt. Könnte man für das Speichern der Events nicht einfach eine einfache Liste an Events (mit benötigter Payload) zu erstellen und nur für das Lesemodell eine DB daraus erstellen. Dann kann ich (wenn ich auf eine vernünftige Programmierung achte) sogar die Payload erweitern/verändern, um auf neue Anforderungen (z.B. nach Jahren) zu reagieren?

[simong]

Erster 👍 super content! Gruß aus Bochum

[SirFoerstar]

Danke für die beiden sehr hilfreichen Videos. Ich werde es beim nächsten Projekt einfach mal versuchen (hoffentlich ist es kein zu großes Projekt). Allerdings würde mich interessieren, wie ich die frisch geänderten Daten in der UI anzeigen soll. Aktuell wird der neue Wert entweder direkt zurückgegeben. Allerdings werden die aktuellen Werte teilweise auch nach dem Create/Update nachgelesen. Das würde mit CQRS aufgrund der Latenz ja vielleicht nicht immer gehen.

[Oelpfanne]

Hab ich den Punkt unter "Warum ist CQRS relevant" falsch verstanden? Die Businesslogik und das Businessmodell sollte eigentl. niemals vom Datenmodell der Datenbank abhängig sein. Dann würde man das Pferd ja von hinten aufzäumen.