Event Sourcing - the only video you need // German

[@stoef]

Das ist das erste Video welches ich von euch empfohlen bekommen habe und muss sagen, dass ich positiv überrascht war. Alle Informationen die ich mir gewünscht hätte, habe ich bekommen. Die Präsentierweise ist super sympatisch und wirkt sehr kompetent. Ich freue mich auf weitere Videos und werde direkt mal anfangen ein wenig mit Event-Sourcing zu basteln.

[@thenativeweb]

Das freut mich sehr, vielen Dank für das tolle Feedback 😊

[@rogerb6378]

Danke für das Thema. Gerne mehr so Themen.

[@thenativeweb]

Vielen Dank für dein Feedback! Das freut mich 😊 In den nächsten Wochen werden noch einige Videos von uns zu diesem Themenbereich kommen…

[@andreasvitz8354]

Hallo @Golo, klasse Video! ich würde mir in einem deep dive follow up Video tatsächlich eine Implementierung der „Bücherei“ wünschen.

[@thenativeweb]

Vielen Dank - sowohl für das Lob als auch für das Feedback 😊

[@woife0705]

Tolles Video und wie immer gut erklärt. Bei dem Beispiel mit der Versicherung musste ich herzlich lachen!

[@thenativeweb]

Vielen lieben Dank! Und was die Versicherung angeht: ja, rückwirkend kann ich darüber auch lachen, aber in dem Moment, wo du in der Situation bist und wo das Realität ist, ist es ziemlich traurig.

[@bernhardeischer8697]

Ich arbeite jetzt das erste Mal in einem DDD, CQRS und Event Sourcing Projekt (Java + Axon Framework/server) und muss sagen das die Lernkurve schon recht steil war. Aus der CRUD Denkweise herauszukommen wenn man das schon immer so eingetrichtert bekommen hat und es immer so gemacht hat ist wirklich nicht leicht. Zugleich finde ich aber DDD, CQRS und Eventsourcing mittlerweile so sexy dass mir schon davor graut irgendwann mal wieder in einem Crud Projekt zu arbeiten

[@thenativeweb]

So ähnlich ging es mir ganz am Anfang auch: es ist sehr schwierig, einen Fuß in die Tür zu bekommen, aber wenn man es einmal verstanden hat, dann fragt man sich schon, warum man jemals gedacht hat, dass etwas anderes eine gute Idee wäre… Wir werden in den nächsten Wochen auf jeden Fall noch einige weitere Videos zu dem Thema bringen, und da wird es über kurz oder lang auch um Axon gehen. Da kommt also noch etwas für dich …

[@soylentpink7845]

Sehr gut, intuitiv und mit der Motivation erklärt! Super Video!

[@thenativeweb]

Freut mich, vielen Dank 😊

[@whereistheline8964]

Vielen Dank für die Vorstellung und Erklärung des Themas. Ich bin ein ehemaliger Business Analyst Team Lead, der innerhalb der gleichen Firma in die Fachabteilung gewechselt ist. Mit dem Wissen aus beiden Domänen schaffe ich es, mich selbst zu verwirren. Mit der Denkweise des Event Sourcings sehe ich ungeahnte Möglichkeiten der besseren Zusammenarbeit von It nahen Rollen im Fachbereich und der IT. Das wird mir helfen!

[@thenativeweb]

Gerade das - die Zusammenarbeit zwischen IT und Fachbereich - profitiert enorm davon. Und auch wenn es in Bereiche wie zB Data-Mesh geht, ist Event-Sourcing eine prima Ausgangsbasis.

[@alexanderbluhm2520]

Super Video. Toll, dass du auch erwähnt hast wie man den aktuellen Stand (z.B. in nem Cache) speichert, damit man die Daten nicht bei jedem Read akkumulieren muss!

[@thenativeweb]

Danke - und ja, das ist ein ganz entscheidender Punkt 😊

[@densanki1985]

Event Sourcing Thema, bisher nicht gehört, super Video, fach und technisch einwandfrei erklärt. Würde mir gerne an Beispiel Projekt das ganze Prototypisch anschauen.

[@thenativeweb]

Kommt noch … 😊

[@anion21]

Gutes Video! Im Gegensatz zum letzten Heise-Artikel, den ich zu dem Thema gelesen habe, wird das Thema in diesem Video finde ich recht gut erklärt. Für manche Anwendungsfälle ist das ein wirklich gutes Entwurfsmuster. Und dann versteht man auch, dass eine Blockchain z. B. auch nur eine vielfach replizierte Event-Sourcing-Datenbank ist.

[@thenativeweb]

Vielen Dank (und BTW: Ich weiß, welchen Artikel Du meinst - den fand ich auch nicht so übermäßig gelungen …)

[@stevenschalm8022]

Nice 😀 machen das jetzt seit ein paar Jahren bei unseren Maschinenintegrationen. Da lassen wir mittels Event-Sourcing den Ablauf der Maschine im 3D-DigiTwin ablaufen. Für Crash-Analysen sehr hilfreich xD

[@thenativeweb]

Das kann ich mir gut vorstellen - genau für so ein Szenario ist Event-Sourcing Gold wert.

[@Mar-Schy]

Super Video, auch wenn es zumindest für mich nur eine Wiederholung ist, aber auch das ist ja wichtig um Wissen zu vertiefen. Sehr gut gemacht, mal wieder 😉

[@thenativeweb]

Das freut mich sehr, vielen Dank 😊

[@emcell2]

Gute Idee für mein kommendes Projekt. Aufschlussreich. Danke!

[@thenativeweb]

Das freut mich 😊

[@ScriptRaccoon]

Ein schönes Beispiel ist auch ein Schachspiel (online oder offline). Man speichert da jeden Zug und nicht nur den aktuellen Zustand.

[@thenativeweb]

Oh ja - das ist ein hervorragendes Beispiel. 😊

[@simong9559]

Mega nice 👍 danke fuer den Content

[@thenativeweb]

Vielen Dank, das freut mich 😊

[@kyrospace]

Ich habe mich im private auf Grund eurer Videos schon beschäfftigt und es probiert es in meinen Side-projects zu verwenden. Das Prinzip ist klar und eigentlich einfach. Aber in der praktischen ist es dann doch nicht mehr so trivial. Besonders die replays bauen haben mich herausgefordert. Unterm Strich habe ich dann meist doch leider wieder auf sowas wie CRUD zurück gegriffen. Aber ich bin da voll bei euch. Event-Sourcing finde ich denn besseren Ansatz und man sollte damit am Ende flexibler sein.

[@thenativeweb]

Es freut mich, dass wir dir eine Anregung geben konnten 😊 Und ja, wenn man auf sich allein gestellt ist, dann kann das am Anfang schon ziemlich schwierig sein, zu entscheiden oder herauszufinden, wie man bestimmte Dinge macht. In den kommenden Wochen werden aber noch einige Videos von uns zu dem Thema kommen, insofern ist das sicherlich für dich auch noch das ein oder andere nützliche dabei.

[@tobiasj8019]

Super erklärt - der Vergleich mit dem girokonto!

[@thenativeweb]

Danke schön, das freut mich 😊

[@TRedCarp]

Hey Golo, vielen Dank für dieses Video. Für mich ist das alles nichts neues aber so klar wie Du das hier beschreibt, motiviert es ziemlich, sich doch mal wieder damit zu befassen. Das Hauptproblem ist in ein vernünftiges Framework dafür zu bauen (wobei ich da, zumindest im privaten Bereich schon recht weit bin). Dinge wie Versionen von Events machen das recht schnell komplex oder Snapshots u.ä. Dennoch, das sollte an den Unis viel mehr in den Fokussierung rücken, als immer nur "einfaches" crud, ist nämlich auch nicht ganz einfach, stört aber gern, danke und Grüße

[@thenativeweb]

Vielen Dank für dein Feedback! Was die Lehre beziehungsweise die Ausbildung angeht, bin ich komplett bei dir. Was ein Framework und Co. angeht: eigentlich solltest du das auch gar nicht selbst machen müssen, denn das ist ja nicht das, was du eigentlich als Kerngeschäft hast - außer du bist Framework-Entwickler. Auch dazu wird in den nächsten Wochen etwas kommen.

[@yt7042]

Danke für das sehr interessante Video. Grundsätzlich würde mich als follow up interessieren welche DB(-en) in diesem Falle am geeignetsten wären. Also sollte man für Event-Sourcing andere DB(-en) verwenden als für CRUD? Ja, für kleine Datenmengen ist das natürlich irrelevant, aber irgendwann wird der Unterschied ja messbar. Vielleicht hast du da ein paar praktische Beispiele mit entsprechenden Vergleichszahlen. Ich wünsche dir auch eine schöne Woche!

[@FunctionGermany]

@@yt7042 du kannst event sourcing problemlos mit RDBMS wie Postgres, MySQL etc benutzen

[@thenativeweb]

Ist notiert - und das wird definitiv demnächst kommen 😊

[@thenativeweb]

Da wäre ich tatsächlich vorsichtig … auf den ersten Blick mag das so sein, aber … 😉 Mehr dazu dann aber in einem eigenen Video, das sprengt sonst den Rahmen eines Kommentars deutlich.

[@djchrisi]

Häufig wird EventStoreDB genommen, aber Kafka ist auch populär und man kann beide auch super kombinieren.

[@djchrisi]

@@thenativeweb Hä? Wieso kommt da was nach? Im Titel heißt es doch "the only video you need" :D

[@sebastianwei542]

Spannend. Interessant wäre ein weiteres Video zu dem Thema in dem es mehr um die Praxis geht. Welche DB? Setze ich auf vorhandene SQL Lösungen auf, setze ich auf Open Source DB, gibt es Event Sourcing DB, oder brauche ich da eine proprietäre Lösung, die sich nur Banken leisten können? Was macht man denn wenn man ein neues Feld in der DB anlegen oder gar löschen möchte? Das DSGVO Thema,? gibts da auch so was wie ein ORM oder kann ich das Konzept Mal total vergessen? Wann eher relationale, nosql oder newsql oder Event sourcing?

[@thenativeweb]

Das wird alles kommen… Gib uns ein bisschen Zeit, aber wir werden auf all diese Fragen in den nächsten Wochen zurückkommen.

[@sLiv256]

Sehr gut erklärt!

[@thenativeweb]

Vielen Dank 😊

[@methitic9806]

Klingt interessant, ein technisches Video dazu wäre mal interessant. Verstehe zum Beispiel nicht wie ich damit ein zusätzliches Feld in einer Tabelle bzw. Datensatz speichern würde.

[@thenativeweb]

Kommt … 😊

[@sdftg2001]

Genau das, was ich meinen Kunden auch predige

[@thenativeweb]

Haha 😊

[@saschab2720]

Super Video 👍 Mich würde auch ein deep Dive interessieren.

[@thenativeweb]

Dankeschön - und ja, mal gucken wann das kommt. Es ist nur eine Frage der Zeit, nicht, ob wir es überhaupt machen.

[@chrisbirkenmaier2277]

Spannendes Thema, sehr interessant und anschaulich erklärt. Danke dafür! Was mich einmal interessieren würde: Im Video hast du ja schon das Thema IoT Daten angesprochen. Habt ihr mit dem Thema bereits Erfahrungen bzw. bereits Best Practices über das Tooling, den TeckStack, .. sammeln können? Zumindest in Kundenkreis geht das Thema aktuell durch die Decke,

[@thenativeweb]

Ja - wir haben einige Kunden im Bereich Industrie 4.0, die sich (zumindest teilweise) auch mit Event-Sourcing befassen.

[@FunctionGermany]

und wie macht man sowas wie "liste alle nicht ausgeliehenen bücher" auf elegante art? subqueries? window functions? oder doch eine performante und indexierte "state" spalte auf dem stammdatensatz, die geupdated wird? ich stell mir das in der breite mit den bekannten query buildern und ORMs sehr messy vor.

[@yt7042]

Es spricht ja nichts dagegen zusätzlich ein Feld für den Status der Buches einzupflegen und nur die Details über die Transaktionen zu ermitteln. Ja, das wäre ein Update, aber in dieser speziellen Konstellation sicher nicht verkehrt. Die Alternative wäre eine zusätzliche ReadOnly Tabelle. Warten wir mal ab was der Fachmann dazu sagt. 🙂

[@FunctionGermany]

@yt7042 ReadOnly kann nur ein weiterer event log sein, d.h. für den aktuellen status musst du wieder subqueries etc. heranziehen. ich hab mir mal event sourcing in laravel angesehen und dort werden projections benutzt, also updatable abbildungen aus der summe aller events eines datensatzes (zB buch). diese projections werden bei jedem neuen event aktualisiert, d.h. du schreibst immer 2x: einmal das event, und dann die projection, evtl. auch mehrere projections.

[@thenativeweb]

Genau so würde ich das auch lösen: Die Events dienen eher dazu, die Veränderungen im Lauf der Zeit zu sammeln - und daraus berechnet man dann die passenden Lesemodelle. In Deinem konkreten Beispiel hieße das, Du bräuchtest eine Tabelle, in der alle Bücher enthalten sind, und immer wenn ein Buch neu in den Bestand aufgenommen wurde, fügst Du es dort hinzu, wenn es entfernt oder gestohlen wurde, löschst Du es, und wenn es ausgeliehen oder zurückgegeben wurde, setzt bzw. entfernst Du einen Marker. Und dann ist es letztlich (sinngemäß) nur ein "SELECT * FROM books WHERE ausgeliehen = true".

[@FunctionGermany]

@@thenativeweb damit ist event sourcing aus DB sicht stumpf eine zusätzliche tabelle - es ersetzt nicht, dass ich einige felder trotzdem im CRUD stil weiterhin pflegen muss, um sie zB in filtern effizient nutzen zu können, richtig?

[@yt7042]

@@FunctionGermany Nein, du kannst ja einfach einen JOIN auf die ReadOnly Tabelle machen.

[@bsdooby]

Gut gefallen; mir stellt sich allerdings die Frage, wie viel technischen “Zusatz”, der auch verstanden/gewartet werden muss (technical dept.), man sich an Bord holt, um Event Sourcing brauchbar zu betreiben: caching, storage, optimization, etc.

[@FunctionGermany]

@@bsdooby interessiert mich auch, ich kommentier um bei antworten benachrichtigt zu werden

[@thenativeweb]

Das ist tatsächlich nicht viel - für eine kleine Anwendung brauchst Du auch nicht mehr als ohne Event-Sourcing: - Eine UI - Eine API mit der Logik - Eine Datenbank als Event-Store Die Lesemodelle kann man für kleinere Anwendungen problemlos im RAM halten.

[@thunderd2k7]

Muss man halt von Anfang an beachten. Für bestehende Projekte oder Software wäre das einführen einer temporalen DB einfacher. Bei jeder Änderung wird der alte Eintrag weggespeichert und man hat quasi Eventdriven auf Datenbankebene und ist auch bei Software von der Stange implementierbar.

[@thenativeweb]

Jein… Also ja, es ist einfacher, wenn man das von Anfang an beachtet. Bei jeder Änderung einfach den alten Eintrag weg speichern, ist aber nur die halbe Miete: du weißt dann zwar, dass sich etwas geändert hat, und du weißt auch, was sich geändert hat, aber du weißt nicht, warum es sich geändert hat. Du kannst nur versuchen, aufgrund der Veränderung zwischen zwei Datensätzen herauszufinden, was die Ursache dafür gewesen sein könnte. Und diese Information ist oft sehr wichtig, und genau diese Information wird mit Event-Sourcing explizit erfasst.

[@ManfredSpecht]

Moin Golo, danke für diese super Video. Mich würde das extrem interessieren und da mal ein erstes Boilerplate, Testprojekt für mich aufsetzen, an dem ich dann vielleicht auch meine Kolleg:innen schulen kann. Wie würdest Du mir da empfehlen vorzugehen? 🤓

[@thenativeweb]

Sofern die Zeit nicht drängt, würde ich Dir empfehlen, Dich noch ein paar Wochen zu gedulden … wir werden all diese Punkte nämlich in den nächsten Wochen nach und nach in Videos bringen …

[@ScreamerD]

Das Video war super interessant. Mir ist allerdings ziemlich schnell der Begriff "Blockchain" durch den Kopf geschossen. Und irgendwie habe ich dann die ganze Zeit darauf gewartet, dass das Beispiel kommt. Als es dann nicht gekommen ist, habe ich mich gefragt, ob ich einen Denkfehler hatte.

[@thenativeweb]

Nein, hast Du nicht - wenn man mal davon absieht, dass eine Blockchain massiv verteilt ist und ein Event-Store nicht, dann ist es ein ähnliches Konzept. Beziehungsweise, es lassen sich Blockchain-artige Dinge auch in Event-Sourcing nutzen.

[@fadecto]

Mir ist hier neben Blockchain auch noch Apache Kafka in den Sinn gekommen. Beim Stichwort "Recht auf Vergessen" auch noch "Data Retention Policy".

[@ScreamerD]

@@fadecto wie würde denn dein anwendungsfall für Kafka aussehen? Persistieren von Events und Abarbeiten von Events sind ja zwei verschiedene Dinge.

[@DanielStoehr203]

Geniales Video. In der Tat hab ich sogar ein aktuelles Projekt, wo ich bisher die Datensätze aktualisiert habe und jetzt plötzlich historische Daten benötigt werden. Dein Beispiel mit dem Konto habe ich verstanden, allerdings bin ich mir unsicher wie man mit Datentypen wie strings oder Boolean umgeht. Hier kann man ja nicht einfach die Werte addieren. Könntest du mir hierzu einen Tipp geben?

[@thenativeweb]

Ich denke, dass wir dazu demnächst ein gesondertes Video machen - einfach deshalb, weil es dazu schon einige Fragen gab, und wir das in einem ausführlichen Video besser beantworten können als hier in einem Kommentar. Grundsätzlich gilt: *Wie* die Werte aus den Events aggregiert werden, muss die Applikation selbst wissen - denn auch bei Zahlen ist ja nicht gesagt, dass die Summe überhaupt relevant ist. Vielleicht sind aus fachlicher Sicht nur das Minimum und das Maximum spannend, oder der Durchschnitt, oder was weiß ich … Das ist also letztlich Interpretationssache, was Du aus den Events machst.

[@semo-s1m]

Schönes Erklärvideo, was u.a. den Abschnitt "Ubiquitous Language" ("Domain Driven Design"; Eric Evans) mit Leben erfüllt.

[@debabbe1023]

Hallo und danke für das interessante Thema. Was mich interessieren würe: Was würdest du machen, wenn Daten nicht in den Events stehen. Z.B., um bei deinem Beispiel zu bleiben, wenn man die Information benötigt, wie viele der Überweisungen Schnellüberweisungen waren? Wenn man diese Information nicht hatte, müsste man die Events anpassen, oder bei den Konsumenten bis zu einem gewissen Zeitpunkt eine Annahme treffen (bis die Events diese Information kennen). Das Problem bei der letzten Lösung ist auch, dass alle Konsumenten davon wissen müssen. Ich könnte mir vorstellen, dass sich bei einer Überweisung nicht häufig etwas ändert, deshalb funktioniert das an der Stelle gut. Hattest du schon mal das Problem, dass du aus den Events nicht alle Daten ableiten / berechnen konntest?

[@steinbohrersteinbohrer1060]

Das war auch einer meiner Gedanken. Wenn der Fachbereich zu mir kommt und eine Auswertung haben möchte, für die alle meine zig-Millionen Events nicht die notwendigen Informationen enthalten? Dann muß ich auch erst meine Event-Speicherung ändern/ergänzen und ein halbes Jahr warten, bis sich genug Events zur Auswertung angesammelt haben. Und bei einer Änderung in der Event-Speicherung, wie ändere ich dann die Replay-Logik, ohne in einem unwartbaren IF-/THEN-ELSE Chaos zu versinken (ist dieses Feld im Event vorhanden? Ist jenes Feld im Event vorhanden? usw.)? Außerdem, wie stelle ich die Reihenfolge aller Event absolut sicher? Wenn meine Anwendung in verschiedenen Zeitzonen (Europa/USA/etc.) verwendet wird? Ist da der sinnvollste Ansatz das Erstellungsdatum eines Events immer in z.B. Ticks umzurechnen?

[@iWantToDetonate]

Ein solches Szenario kann es nicht geben. Entweder kann ein Programm eine Schnellüberweisung ausführen oder nicht. Die Information ist entweder Teil des Prozesses "Überweisung ausführen" oder ein eigener Prozess "Schnellüberweisung ausführen". Ist dem Prozess die Information dass es sich um eine Schnellüberweisung handelt nicht bekannt, wie soll der Prozess dann eine Schnellüberweisung ausführen? Man muss sich von der Vorstellung von "Datenstrukturen" wie wir sie aus relationalen Datenbanken gewohnt sind lösen. Welcher Prozess angestoßen wurde und mit welchen Daten dieser gefüttert wurde bilden zusammen das "Event", und das ist alles was wir brauchen da wir hieraus jeden beliebigen Zustand ableiten können. Garnieren wir unseren Event-Log noch mit einer DateTime Angabe, können wir auch jede zeitliche Abfolge beliebig rekonstruieren. Dementsprechend ist auch für Events welche die Angabe zur Schnellüberweisung nicht haben keine Annahme nötig. Es kann gar keine Schnellüberweisung gewesen sein da die Anwendung dieses Prozess gar nicht konnte.

[@iWantToDetonate]

@@steinbohrersteinbohrer1060 Die Replay-Logik lässt sich völlig generisch aufbauen. Wenn deine Projection Information "X" enthalten soll, nimmt deine Replay-Logik aus dem neustem Event welches Information "X" enthält dessen Wert. Wenn es kein Event mit diesem Wert gibt dann ist der Wert null. Das ist völlig ausreichend um jede beliebige Projection mit jeder historisch jemals vorhandenen Information zu erzeugen. Für die Reihenfolge genügt eine simple fortlaufende Sequenz. Damit ist die Zeitzone des Erstellungsdatums irrelevant, wobei es u.U. sowieso sinnvoll sein kann bei internationalen Anwendungen solche Angaben in einem möglichst neutralem Format zu speichern (z.B. UTC) und erst auf dem Endgerät des Anwenders zu formatieren.

[@brubbeldi]

Hallo, tolles Thema! Könnt ihr ein gutes Buch hierzu empfehlen, um das Gehörte vertiefen zu können? Um eben auch die richtigen Fragen zu stellen? Sei es an sich selbst, oder das Team. Danke euch!

[@thenativeweb]

Vielen Dank 😊 Leider wird's, was Literatur angeht, sehr dünn. Wir sind tatsächlich dabei, ein Buch zu dem Thema zu schreiben - das wird aber noch ein Weilchen dauern.

[@brubbeldi]

@@thenativeweb Das klingt ja toll. Darauf kann man sich ja schon jetzt freuen!

[@j.m.manhard]

Eine Frage: wie macht man das mit JOINs? Haufig gibt es eine Art Komplett-Ansicht in einer Anwendung. Liste aller Entities, sortiert nach Foo, danach mach Bar und ohne die, die Bedingungen X, Y und Z erfüllen. Mit SQL ist das kein Thema, aber bei Events.... müsste ich da die ganzen ORDER BY und WHERE und JOINs selbst in meinem Client basteln? Oder gibt es da was schlaueres wir eine VIEW vorzuhalten, die immer den neuesten Snapshot der Daten enthält und dann darauf zu joinen? Gibt es vllt schon Datenbanken, die das für mich tun?

[@thenativeweb]

Kurze Antwort: es gibt keine Joins. Tatsächlich würde man genau das machen, was du am Ende vorgeschlagen hast: eine Tabelle vorhalten, in der bereits die gejointen Daten enthalten sind, so dass du die dann sehr einfach auslesen kannst. Das ist überhaupt eines der Kernprinzipien bei dem Thema: du hast ein komplett anderes Modell zum Schreiben als zum Lesen. Darauf werden wir in einem der nächsten Videos aber noch mal im Detail eingehen, vielleicht klärt sich dann einiges von deinen Fragen noch.

[@maxkf4386]

Sehr interessantes Video. Wie verhält sich dann eine Transaktion beim ändern dieser? Gibt es dann eine zusätzliche Spalte des Event Logs oder wird dann ein neues Event Log angelegt? Beispiel wäre, es müsste zusätzlich noch das Kartenterminal gespeichert werden, was bisher noch nicht notwendig war.

[@thenativeweb]

Das ist dann ein neuer Eventtyp. Also im simpelsten Fall hast Du dann statt "Kartenzahlung durchgeführt" ein "Kartenzahlung durchgeführt V2", was dann die Informationen zum Terminal enthält. Deine Anwendung muss dann entweder mit beiden Event-Typen umgehen können, oder Du schreibst Dir einen sogenannten "Upcaster", der die alten Events in die neuen transformiert und zB einen Default-Wert setzt, so dass Du in der Anwendung dann nur mit den V2-Events zu tun hast. Es gibt noch ein paar mehr Optionen, aber das wäre mal eine gängige Vorgehensweise.

[@niccommander]

Danke für das Video, sehr gut erklärt :). Ich habe gerade schauen wollen, was ihr beim wolkenkit als Datenbank nehmt, aber die gh-links (z.B. auf eurer Webseite) führen nur zu 404 Seiten. Ist das gewollt?

[@thenativeweb]

Jain … also wir entwickeln wolkenkit nicht mehr weiter, und das Produkt ist quasi abgekündigt. Deshalb gibt es die Zielseiten (wie zB auf GitHub) nicht mehr. Da wir im Moment aber auch dabei sind, eine von Grund auf neue Webseite zu entwickeln, und die alte Seite leider etwas Kraut und Rüben im Code ist, haben wir beschlossen, die Navigation dort nicht mehr anzupassen. Danke für das Feedback zum Video 😊

[@thenativeweb]

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Event-Sourcing-Die-bessere-Art-zu-entwickeln-10258295.html

[@FalcoPunch182]

Was ich mich dabei frage: wenn ich eine Suche auf den Bestand implementieren will, müsste ich dann alle Events "Buch in Bestand aufgenommen" durchgehen und davon dann alle Events "abziehen", die sagen "Buch wurde gestohlen", "Noch wurde zerstört", "Buch ist ausgeliehen"? Wie würden solche Sachen implementiert werden??

[@FunctionGermany]

@@FalcoPunch182 bei laravel benutzt man dafür projections, heißt bei anderen frameworks vielleicht ähnlich. bei jedem event INSERT machst die anwendung auch ein UPDATE auf die projection, die den aktuellen zustand "abbildet" (daher der name).

[@thenativeweb]

Im Event-Store sammelst Du die Events wie "Buch wurde in den Bestand aufgenommen", "Buch wurde gestohlen", "Buch wurde ausgeliehen", und so weiter. Daraus die Frage zu beantworten, "welche Bücher haben wir aktuell im Bestand", hieße tatsächlich, alle Events durchzugehen und die von Dir beschriebene Logik anzuwenden. Das ginge - wäre aber natürlich super umständlich und langsam … Deshalb nimmst Du eine zweite Datenbank (dazu gleich mehr), und legst in ihr eine Tabelle an, für den aktuellen Bestand. Und dann baust Du eine Projektion: - Immer, wenn ein Buch neu in den Bestand aufgenommen wurde, hinterlegst Du das Buch in besagter Tabelle. - Immer, wenn ein Buch gestohlen wurde, entfernst Du es aus dieser Tabelle. - Immer, wenn ein Buch aus dem Bestand genommen wurde, entfernst Du es ebenfalls aus der Tabelle. Alle anderen Events ignorierst Du, da es keinen Einfluss auf den Bestand hat, ob ein Buch zB ausgeliehen wurde oder nicht (dann ist es zwar gerade nicht ausleihbar, aber trotzdem in Deinem Bestand). Damit hast Du quasi eine live aktualisierte, immer aktuelle, vorberechnete Tabelle mit den von Dir gewünschten Daten, und die kannst Du abfragen mit einem simplen "SELECT * FROM", was dann rasend schnell geht. Nun musst Du natürlich nicht zwingend eine zweite Datenbank dafür nehmen - Du kannst diese Tabelle auch einfach im RAM haben. Damit werden Deine Abfragen rasend schnell, und sollte Dein System crashen, baust Du Deine In-Memory-Tabelle aus den Events wieder neu auf. Bevor Du jetzt - eventuell - einwendest, dass das aber ganz schön umständlich ist, sei dazu noch gesagt: Der Punkt ist, dass im Gegensatz zu einem klassischen System Du eine solche Tabelle auch im Nachhinein (!) noch definieren oder auch in ihrer Struktur ändern kannst. Alles, was Du machen musst, ist die Definition anzupassen, und einen Replay laufen zu lassen, um die Tabelle zu befüllen. Und das ist die Flexibilität, die ich mit "Re-Interpretieren der Vergangenheit" meine, und die das Konzept so mächtig macht. Das heißt, um es in einem Satz zusammenzufassen: Im Event-Store optimierst Du auf das Schreiben, weil Du dort mit einem Append-Only-Log arbeitest. Für das Lesen arbeitest Du mit optimierten Lesemodellen, wobei Du da frei in der Wahl der Technologie bist, und die Leseseite jederzeit nach Belieben umbauen kannst, ohne Daten zu verlieren, weil Du stets die Events als "Single Source of Truth" zur Verfügung hast.

[@anion21]

Man will normalerweise aus Effizienzgründen vermeiden, eine ganze Transaktionshistorie für Abfragen des status quo durchzuiterieren. Für alle Abfragen, die man auf den Status quo machen will, braucht man deshalb, wie auch im Video angedeutet, eine Art Caching-Mechanismus.

[@FunctionGermany]

@@anion21 in der praxis heißt das, dass man die klassischen CRUD tabellen und spalten trotzdem braucht und einfach immer 2x mit der DB spricht: ein mal event inserten, ein mal die projection (so heißt es bei laravel) updaten. denn ein in-memory cache braucht sonst über die jahre zunehmend lange beim booten der anwendung oder wird zu groß etc.

[@serumdev]

es wäre cool wenn du als follow up ein beispiel projekt zeigen könntest insbesondere mit den replays. dafür könntest du z.b. die zwei beispiele die du bereits genannt hast eines davon wählen; also z.b. bankkonto auszüge oder das mit den bücher vergabe.

[@derinteressierte8732]

also mich interessieren alle ideen die von dem standad abweichen. das aktuelle thema fand ich sehr erfrischend ;))

[@thenativeweb]

Danke schön, das freut mich 😊

[@davidberschauer1330]

Lässt sich EventSourcing auch auf verteilte Datenbanken anwenden, die miteinander synchronisiert werden sollen? Wenn ich beispielsweise eine Datenbank auf einem Server habe und eine App, die offline Daten sammelt, reicht es dann aus, die Listen der Events aneinander zu hängen? Natürlich ohne Duplikate, also ab dem letzten gemeinsamen Event. Ist es hier zwingend erforderlich, dass die Reihenfolge durch synchronisierte Zeitstempel eingehalten wird? Oder scheitert es daran, dass man fachlich ungültige Zustände erreichen kann? Hat jemand Erfahrung damit?

[@christiankarsten664]

Das könnte gehen. Zum einen kann man fachlich ungültige Zustände eigentlich nicht erreichen, da ein Event ja erst publiziert wird wenn die Domainlogik schon gelaufen ist. (Daher sind alle Eventnamen ja in in der Vergangenheitsform und beschreiben den Istzustand) Und zum anderen kommt als Middleware in solchen Architekturen ja idR. ein Messagebroker zum Einsatz damit man überhaupt eine verteile Architektur realisieren kann die z.B. aus mehreren PODs in einem Kubernetes Cluster besteht. Wenn der die Events zwischenspeichern kann sollte es gehen.

[@thenativeweb]

Wie so oft - it depends. In diesem Fall hängt es davon ab, was Deine Business-Regeln und deren Constraints sind, ob zB das offline Sammeln und verspätet "hochladen" ein gangbarer und zulässiger Weg ist oder nicht.

[@thenativeweb]

Wie Du schon ganz richtig sagst: "Könnte". Es hängt letztlich vom Anwendungsfall ab.

[@ThomasSchneiderGotha]

Gibt es die Weeklies und Dictionaries such als Audio-Podcast? Auf welche Stolperfallen sollte achten, wenn man EventSourcing mit CouchDB umsetzen möchte?

[@thenativeweb]

Zu deiner Frage mit dem Podcast: nein, das gibt es leider nicht. Das haben wir schon einige Male intern diskutiert, uns aber immer wieder dagegen entschieden. Was deine Frage zu Event-Sourcing und CouchDB angeht: das lässt sich schlecht in drei Sätzen in einem Kommentar beantworten. Wir werden aber demnächst sicherlich ein Video machen, worauf man generell im Hinblick auf die Auswahl der Datenbank für dieses Thema achten sollte.

[@Mokelet2]

Ah, ok. Das heißt, ich nutze den Event-Store lediglich als „Datenkrake“ und führe lesende Zugriffe auf einer anderen Datenquelle aus. Das löst bei mir einige Knoten im Kopf. Das heißt aber auch, dass ich - um bei dem Beispiel zu bleiben - Informieren über das Buch (Titel, Autor, Erscheinungsjahr, etc.) zum einen im Event festhalte, und zusätzlich in der Datenbank für die Lesezugriffe?

[@thenativeweb]

Ganz genau 👍

[@tobymoby8524]

Also vll bin ich da ja anders getriggert, aber wenn ich eine software entwickle die gewisse daten speichert und es auch nur eine ameisengroße chance gibt dass man nicht weis welcje daten später einer analyse gelten, ist die EINZIGE logische Konsequenz dass man keine datensätze löscht oder verändert sondern neu anlegt um sich eine historie zu bewahren. Es ist immer töricht zu denken, dass man die anforderungen und absichten der stakeholder in gönte kennt.

[@thenativeweb]

Das Problem, wenn man einfach nur eine neue Version des Datensatz zu speichert, ist, dass man nicht weiß, warum sich eine Veränderung ergeben hat. Du hast zwar zwei Snapshots, die du vergleichen kannst, aber du musst daraus wieder Rückschlüsse auf die fachlichen Beweggründe für Änderungen ziehen. Das ist das, was ich an dem im Video beschriebenen Konzept so extrem spannend finde: du kennst die Gründe, warum sich Dinge verändern.

[@kyrospace]

PS: Was mich aus der der Praxis interessieren würde ist: Macht man einen log für alles oder pro Entität order ...

[@thenativeweb]

Du hast üblicherweise ein Log für alle Events, weist den Events aber ein "Thema" zu. Und wenn Du an Thema X interessiert bist, holst Du aus dem Gesamt-Event-Strom nur die, die zu diesem Thema gehören. Damit musst Du nicht jedes Mal Millionen oder Milliarden von Events durchgehen, sondern kannst zielgerichtet diejenigen holen, die relevant sind.

[@holgerwinkelmann6219]

Die Serie muss auch mal auf English kommen !

[@thenativeweb]

Vielen Dank für die Anregung - das schaffen wir zeitlich leider nicht. Das hatten wir in der Vergangenheit schon mal versucht, aber der Aufwand ist den Nutzen nicht wert.

[@Leon-cm4uk]

Und was ist, wenn Daten wirklich gelöscht werden sollen, weil ein Nutzer dies in Auftrag gibt? Das ist ja eine legitime Forderung und auch vom Datenschutz so gewollt, dass diese Option existiert. Spätestens da müssen Daten ja überschrieben werden. Also klar aus unternehmenssicht ist das unschön, aber die Rechte existieren nunmal und das ist auch gut so, gerade wegen des Schutzes personenbezogener Daten.

[@christiankarsten664]

Die Frage habe ich mir damals auch gestellt. Herausgekommen ist das mit EventSourcing einen konformen Löschprozess auch beschreiben kann. Das läuft so ab: Das Event welches den Vorgang anlegt erzeugt in einer Timerkomponente einen Timer der zum errechneten Löschdatum ein weiteres Event erzeugt "VorgangLöschdatumEreicht". Dieses Event wird dann irgendwann mal ausgelöst und in der Domainlogik verarbeitet die erst einmal prüft ob dem Löschen irgendwas entgegensteht (anderweitig belegte Ressourcen, offene Forderungen.... was weiß ich) Kommt diese Logik zum Schluss das gelöscht werden kann wird das Event "VorgangGelöscht" erzeugt. Und der Eventhändler zu diesem Event löscht dann alles, inclusive aller Events zu dieser AggregateRoot im EventStore. Manuelle Löschung geht dann im Frontend einfach über einen Button das passende Event manuell auslöst.

[@thenativeweb]

Wie im Video erwähnt (siehe kzbin.info/www/bejne/qaScqKGfrah6iLs) gibt es dafür verschiedene Ansätze, die sich in Komplexität und Datenschutzkonformität unterscheiden. Zu diesem Punkt gibt es nicht _die eine_ richtige Lösung, sondern da muss man gucken, was von den verfügbaren Optionen passend ist. Die Spanne reicht von "DSGVO ignorieren, weil es sich um Trivialdaten handelt und das Risiko praktisch Null ist" bis zu "den kompletten Event-Store migrieren und während der Migration unerwünschte Events ausfiltern". Und zwischen diesen beiden Extremen gibt es noch etliche weitere Optionen.

[@guntherspecht4238]

Ich hatte die ganze Zeit einen Begriff im Kopf, während ich das Video gesehen habe: Kafka Klar bei Kafka geht es um Messaging, aber letztendlich ist Kafka ein Event-Log und wenn man es nicht löscht hat man damit auch Event-Sourcing. Ich war am Ende überrascht, dass der Begriff nie gefallen ist.

[@hansschenker]

für mich CRUDL L für List!

[@thenativeweb]

Dinge aufzulisten ist letztlich auch nur ein Read, oder?

[@dustmarcus]

Ich wünsche mir ein Video, das sich mit dem Löschen befasst.

[@thenativeweb]

In den nächsten Wochen werden einige Videos von uns zu dem Thema noch kommen, und da wird auch dieser Punkt sicherlich noch mal genauer beleuchtet werden.

[@bullenschweinful]

Ich würde Interessierten das Buch "Designing Data-Intensive Applications (Martin Kleppmann, 2017)" sehr empfehlen. Ist zwar schon etwas in die Jahre gekommen aber sehr gut lesbar und und geht auf viele technische Fragen ein. @Golo: Obwohl mir das Thema nicht ganz neu ist habe ich mich bei Deiner einführenden Motivierung vor Lachen gekringelt. Danke dafür 😂

[@thenativeweb]

Das Buch von Martin Kleppmann ist super 👍 Das kann ich auch nur wärmstens empfehlen.

[@DJone4one]

2:00 Naja wenn ich mir so Software wie Vario angucke, da gibt es auch die Möglichkeit z.b. Mit Bestandführung, Gesperrt, Ohne Bestandsführung, usw. dem Artikel mitzugeben. Also noch andere Zustände des Artikels, außer 'da' und 'nicht da'. Denn ich als Andwender von ERP Software in der Logistik habe verschiedene Fälle. Mal sind die Papiere Falsch, oder die Ware ist die Falsche wurde aber schon vom Kollegen ins System aufgenommen, usw.

[@thomasfuchsberger3912]

Wenn Audit nicht zwingend nötig ist läßt sich das auch sehr gut mit CRUD und zusätzlich elasticsearch umsetzen…

[@thenativeweb]

Ähm, nein. CRUD + Elasticsearch ist nicht pauschal eine gangbare Alternative zu Event-Sourcing, auch wenn man kein Audit-Log benötigt. Allein schon, ob der Einsatz von Elasticsearch überhaupt sinnvoll ist, hängt massiv von der Art der Daten und dem Anwendungsfall ab.

[@thomasfuchsberger3912]

@ danke für dein Statement. Ich genau so etwas in ein Email Gateway integriert und es funktioniert eigentlich völlig reibungslos. Auch durch die elasticsearch Language lassen sich eigentlich alle Auswertungen super abbilden.

[@jurgensieben1437]

Ich sehe das Video und bin ehrlich fassungslos: Was Du auf 30 Minuten Video beschreibst ist die Idee eines historisierenden Datenmodells, das in Datenbanken seit hundert Jahren verwendet wird. Nicht beachtet werden weitergehende Probleme, etwa die Unterscheidung, wann etwas fachlich gegolten hat und wann die Datenbank davon erfahren hat und ähnliches. Fassungslos macht mich, wie sehr die Entwicklerdenkweisen zwischen Anwendungsentwicklern und Datenbankentwicklern mittlerweile auseinanderdriften ...

[@thenativeweb]

Es war ja auch nur eine Einführung - dass ich da nicht auf alle Details eingehen kann, denke ich, versteht sich von selbst. Klar gibt es da noch tausend Kleinigkeiten, aber man will ja jemanden für den Einstieg auch nicht direkt überfordern (es ist für viele Entwicklerinnen und Entwickler ja schon "anders" genug). Aus meiner Sicht trägt die Lehre hier eine ganz massive Mitschuld, weil Dir das klassische relationale Datenbankmodell + CRUD eben in 99,9% der Fälle - wie im Video erwähnt - als "die ultimative Wahrheit" vermittelt werden.

[@hobe4576]

Sorry, aber dieser Kommentar zeugt er davon, dass Du das Konzept "Eventsourcing" und damit die Intention des Videos nicht richtig verstanden hast. Vielleicht widerlegt das die Überschrift, dass dieses Video das "einzige sei was man dazu gucken müsse" :). Ich finde übrigens, dass es hierfür deutlich bessere Beiträge gibt - ohne dem Verfasser zu Nahe treten zu wollen...