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