Was ist CQRS? // deutsch

[@lokthar6314]

Dein Kanal hat viel viel mehr Views verdient. Super content, vielen dank!

[@thenativeweb]

[gr] Vielen, vielen Dank 😊

[@ragsnasramoninus2443]

Sehr schön, knapp und verständlich erklärt. Danke!

[@thenativeweb]

[gr] Freut mich, vielen Dank 😊

[@FunctionGermany]

2 datenbanken? wenn es einen performance gain geben soll, dürfen die daten ja nicht als teil einer command request nicht in die read-DB übertragen werden. das muss asynchron (also evtl. erst nach der HTTP antwort) oder zyklisch per (cron)job erfolgen. das offensichtliche problem ist, dass die daten dann chronisch out of date sind. zB. ich hab ne SPA mit ner tabelle und nem "add item". nach erfolgreicher antwort auf "add item" wird die tabelle aktualisiert, aber das neue item fehlt. tja.

[@andreasmewald2439]

Wie werden die Datenbanken synchronisiert? Sprich die Write-Information muss ja irgendwie in die Read-DB wandern.

[@danielc.oderbolz8754]

Ja, das ist eben die Krux und vermutlich auch der Grund, warum dieses Konzept nicht breiter angewandt wird. So muss ja gerade der Sync-prozess genau dieses Problem lösen - er muss also (hoch)optimiert auf die "Schreib" DB lesend zugreifen. Ich kann mir das eigentlich nur so vorstellen, dass der "Leseteil" im RAM vorgehalten wird - nur machen das heutige RDBMS schon heute so (und ersparen es den Applikationsentwicklern, selbst so etwas bauen zu müssen).

[@andreasrudischhauser3679]

Was macht denn die UI wenn z.B. der POST zum anlegen eines Datensatzes diesen nicht direkt zurück gibt? Mindestens die Id des Kunden müsste doch (via http 201) zurück gegeben werden sodass der fertige Datensatz dann vom Query Service geladen werden kann. Wartet die UI so lange? Oder kann man die REST API so bauen, dass diese intern den command sendet und danach die query ausführt und das Ergebnis zurück gibt sodass es nach außen wie CRUD aussieht?

[@thenativeweb]

Das ist eine sehr gute Frage, auf die es verschiedene Antworten gibt, wie man das Problem lösen kann. Die erste Möglichkeit besteht darin, dass man die ID clientseitig generiert - wobei das natürlich nur praktikabel ist, wenn man mit UUIDs und nicht mit numerisch aufsteigenden IDs arbeitet (was in einem verteilten System aber vermutlich ohnehin der Fall sein dürfte). Der Vorteil daran ist, dass es sehr einfach zu implementieren ist, der Nachteil, dass es zu Konflikten führen kann und dem Client eine Verantwortung aufbürdet, die er nicht haben sollte. Die zweite Option besteht darin, die ID des neu erzeugten Datensatzes / Aggregates eben doch im Response-Body zurückzugeben. Das wäre quasi die pragmatische Ausnahme von der Regel. Der Vorteil daran ist, dass es ebenfalls einfach zu implementieren ist, man die ID aber sicher auf dem Server vergeben kann, der Nachteil besteht aber in der Verletzung des CQRS-Patterns gemäß Lehrbuch. Die dritte Möglichkeit generalisiert die zweite: Jedes Command (unabhängig davon, ob es einen neuen Datensatz / Aggregate erzeugt) erhält üblicherweise vom Server eine eindeutige Command-ID zugewiesen, die im Domain-Event wiederum als Causation-ID aufgegriffen wird, so dass man Events zu Commands zuordnen kann. Das kann man sich zu Nutze machen, um die ID des Datensatzes / Aggregates aus dem Event auszulesen. Der Vorteil daran ist, dass man - anders als bei Option 2 - alle Commands gleich behandeln kann, der Nachteil ist aber, dass man immer stets auf Event hören / warten muss, bis man eine ID in Händen hält. Was aus diesen drei Optionen ist nun empfehlenswert? Das hängt vermutlich davon ab, wie man die jeweiligen Vor- und Nachteile letztlich bewertet. Wir haben bei uns alle drei Varianten im Lauf der Zeit gehabt, und inzwischen verwenden wir Option 2 + 3 gemeinsam. Das heißt, wir geben bei jedem Command als Response des POSTs die Command-ID und die Datensatz-/Aggregate-ID zurück. Ja, das ist nicht ganz richtig gemäß Lehrbuch, aber ein pragmatischer und in der Praxis gut funktionierender Ansatz. Insofern war es im Video nicht ganz korrekt, zu sagen, der Response-Body ist immer und in jedem Fall leer. Wichtig finde ich aber, dass man hier eben nur solche Informationen zurückgibt, die sich auf das beim Server abgegebene Command beziehen, und keine Daten, die auf das Ergebnis des Commands schließen lassen. Hilft Dir das weiter?

[@andreasrudischhauser3679]

@@thenativeweb Alle Varianten lösen zumindest das Problem, dass man eine Referenz braucht um das soeben erzeugte Objekt auch wieder zu finden. Meine eigentliche Frage ist, wie man vorgeht, wenn es bislang eine REST API gibt welche bei einem POST den kompletten (gespeicherten) Datensatz zurück gibt. Um dahinter das CRUD System durch ein CQRS System auszutauschen wäre die Idee nun quasi "CQRS behind CRUD". Das geht natürlich nur (ohne crazy hacks), wenn alles synchron abläuft. Der Endpoint POST /Customers kann ja intern zuerst das Command absenden und dann mit der ID (je nach Variante) danach den Query Service nutzen um die Daten zurück zu geben... Danke

[@thenativeweb]

Genau, das wäre dann letztlich die Vorgehensweise - quasi eine CRUD/REST-Fassade um die CQRS-API. Wie diese dann wartet, bis dann lässt du es genau die gleiche Frage, wie wenn man das Ganze aus der Sicht eines Clients betrachtet.

[@black-snow]

Nebenwirkung oder Nebeneffekt - nicht Seiteneffekt ;) Seitenwirkung gäbe es noch, aber das schmerzt auch eher beim Lesen / Hören.