1.9.2021 |

Notizen zum Webinar "DDD, CQRS und Event-Sourcing"

Als Teil der Techlounge Summer Edition fand am 20.08.2021 das Webinar DDD, CQRS und Event-Sourcing mit Golo Roden statt.

Hier sind ein paar Notizen zum Webinar.

Anfang

  • DDD, CQRS und Event-Sourcing sind einzelne unabhängige Konzepte - passen aber gut zueinander/Ergänzen sich
  • Software wird zur Lösung eines Problems in der realen Welt geschrieben - nicht wegen des Software Schreibens willen.
  • Entwickler sollten "Fachlich"-Denken da Technik bzw. Technologien nur ein Mittel/Werkzeug zur Problemlösung ist.
  • Der Anwender interessiert sich normalerweise nicht für die verwendete Technologie. Er will nur das sein Fachlicher Vorgang funktioniert
  • DDD sollte wie Design Pattern verstanden werden, bedeutet: Der Grundgedanke ist Wichtig - Umsetzung ist abhängig von Programmiersprache bzw. bei DDD von der Fachlichkeit

DDD

  • Domain Driven Design - Im Mittelpunkt die Fachlichkeit
  • Einheitliches Wording verwenden! (Kunde, Customer, Endkunde, User, Anwender, Benutzer, Client, Consumer, Verwender ... - führt garantiert zur Verwirrung!)
  • Techniksprache nicht in die API oder ins UI bringen! Language Gap (Nutzer versteht nicht "UpdatePosition", sondern würde wohl eher das Wort "Spielzug" beim Brettspiel verwenden)
  • Command: VERB(imperativ) + SUBSTANTIV (zieheFigur, storniereAuftrag, ...)
  • Commands können ausgeführt oder verweigert werden
  • (Domain-) Events: ist die Reaktion auf ein Command. SUBSTANTIV + VERB(Vergangenheit) - (figurGezogen, auftragStorniert, ...)
  • Ein Command kann 1 bis n Events nach sich ziehen bzw. m Commands können auch 1 Event auslösen
  • Ein Command kann ein (konsistenten) State beeinflussen, was wiederum ein Event auslöst, welches wiederum den State beeinflussen kann
  • Abwegen: Parallelität VS. Konsistenz - Konsistenz ist aber relativ (sofern es nicht um ein Atomkraftwerk oder ähnliches geht ;) )
  • Aggregate: Transaktionale Grenzen
  • Innerhalb einen "Bounded Context" sollte klar definiert sein welches Wording für was steht

Event-Sourcing

  • Im allgemeinen ein Vorgehen von Datenspeicherung
  • Create und Read sind unproblematisch - Update und Delete nicht
  • EventStore: Wenn keine Daten gelöscht (Append only) werden kann immer eine Historie erzeugt werden
  • Events können nicht zurück genommen werden - Es muss ein gegen Event erzeugt werden um einen "alten" Stand herzustellen
  • Nachteil: Speicher, DSGVO

CQRS (Command-Query-Responsibility-Segregation)

  • Üblicherweise: 1 Normalform = gut zu lesen, 5 Normalform = gut zu schreiben, in der Praxis wird meist 3. Normalform verwendet
  • Kernidee bei CQRS: ein Command an eine API und ein Query an eine andere API geschickt -> Meist dann auch 2 Datenbanken (eine Schreiboptimierte und eine die fürs Lesen optimiert ist)
  • Datenbank zum lesen sollte nicht normalisiert werden (Performance)
  • CPT-Theorem: Availability, Consistency, Partition tolerance -> Entweder AP oder CP
  • Auch wenn nicht immer sofort Einsehbar aber meist ist Verfügbarkeit (availability) wichtiger als Konsistenz
Zur Übersicht
Patrick Schaper

Mehr vom Devsquad...

Sven Röttering

Zx - A tool for writing better scripts

Umut Tufanoglu

Easily send beautiful and templated emails with mjml.io & Java

Hallo

Wir sind für Sie da und freuen uns auf Ihre Fragen oder Ihr Feedback.