Flow Design und DDD/CQRS

[lbattermann]

Hallo,

ich habe mich in den letzten Tagen mal ein bisschen mit dem Thema DDD/CQRS beschäftigt. Die Ideen hinter sowohl DDD als auch CQRS finde ich sehr einleuchtend und charmant. Ebenso ist die Verbindung mit Event Sourcing spannend. Jetzt frage ich mich allerdings, wie bzw. ob man das Ganze sinnvoll mit Flow Design verbinden kann?

Es gibt da aus meiner Sicht ein paar Herausforderungen:

1. Es gibt noch kein Standard CQRS Pattern. CQRS besagt ja erstmal nur, dass Commands und Queries getrennt werden sollen, so ähnlich wie CQS (beschrieben von Bertrand Meyer). (CQRS ist noch ein bisschen strenger als CQS in dem Sinne, dass es für Commands und Queries verschiedene Schnittstellen/Objekte gibt.) Trotzdem gibt es natürlich ein gemeinsamen Kern bei vielen CQRS Umsetzungen, die Command- / Event-Handler, Aggregates, Read Models, ggf. Bus Systeme enthalten. Die Implementierungsdetails sind aber oft sehr unterschiedlich, zumindest nach meiner Beobachtung.

2. Ich finde, dass ein CQRS Framework ein recht großes Rauschen produziert. Vielleicht ist es Gewöhnungssache, aber irgendwie dominiert das Design Pattern doch die ganze Zeit und lenkt ab. Infrastruktur und Anwendungslogik sind bei einigen Umsetzungen stark vermischt. Es wäre schön, wenn die CQRS Library, die man verwendet, die Infrastruktur so gut es geht wegkapseln würde. (Vielleicht gibt es da passende Frameworks? Ich kenne nicht alle.)

3. Mein erster Gedanke bzgl. der Integration von FD und CQRS ist, dass man seine Domain Logik mit FD umsetzt. Dann könnte in den Command- und Event-Handlern einfach die Public API der Domain Logik aufgerufen werden. Ebenso in der Aggregate Root. Dann wäre CQRS einfach ein Gerüst, welches um den Kern der Anwendung herum gebaut wird. Allerdings ist der Gedanke des Aggregate ein sehr objektorientierter. Hier wird ja aus der Event Historie der Objekt Graph aufgebaut. Irgendwie passt das schlecht mit FD zusammen.

4. Wie verbinde ich FD und Event Sourcing? Das Problem ist, dass dem FD kein DDD vorausgeht. Es geht um Datenflüsse und um Input und Output. Vielleicht kann man dies einfach lösen, indem man im Vorfeld die Commands und Events modelliert. Events werden dann einfach persistiert und die Repositories (bzw. die Datenbank Adapter etc.) laden ihre Daten aus der Eventhistorie.

Ich finde die Konzepte von DDD, CQRS, Event Sourcing und Flow Design super und würde gerne diese Welten irgendwie zusammen bringen. Hat jemand Erfahrungen damit, und möglicherweise Antworten auf meine oben beschrieben Punkte?

[Ralf Westphal]

Schau doch mal hier rein:

https://github.com/ralfw/cashbook_incremental

Da bringe ich Flow Design und Event Sourcing zusammen. Das ist kein riesiges Beispiel... aber es wächst.

Und ansonsten: Mir scheint, dass du ein wenig zu ehrfürchtig vor den Akronymen stehst. Oh, DDD! Oh, CQRS! ;-)

Überall gibt es ein paar gute Ideen. Aber am Ende kommt es darauf an, nicht ein Akronym nach dem Buch zu leben, sondern laufende und wandelbare Software auf die Straße zu kriegen.

Steig doch nicht oben ein mit einem Ideal, sondern fang von unten an.

"Dass dem FD kein DDD vorausgeht": Warum sollte das auch? Wenn du dich hinsetzt und großartig überlegst, was es für Aggregate und Entitäten geben sollte, betreibst du vorzeitige Optimierung.

Stattdessen lass dich überraschen von dem, was entsteht, während du mit FD entwirfst und dann implementierst. Da entstehen Muster. Die kannst du vielleicht mal in Entitäten und Aggregate übersetzen. Schön, dass DDD Begriffe dafür zur Verfügung stellt. Aber mit denen anfangen...

Von DDD à la Jimmy Nilsson kann ich nur abraten. Eric Evans hat gute Ideen geliefert - aber in einem Buch, das dem SRP widerspricht. Und Vaughn Vernon hat versucht, es in einem Rundumschlag zu richten. Leider verliert der sich aber aus meiner Sicht im Wald der vielen DDD Bäume, so dass es wieder nicht praktisch anwendbar wird.

DDD und CQRS haben viele Gesichter. Was ist aber der Kern?

Bei DDD gibt es zwei Teile: micro und makro.

Makro ist z.B. Ubiquitous Language und Bounded Contexts. Micro ist Entities usw., also der OO-Teil.

Was ist deren Kern?

Makro: Sei präzise! Klare Sprache, klare Grenzen, klare Domäne.

Micro: Kapselung, SRP - App/Services vs Aggregate/Entity/VO.

Und was ist der Kern von CQRS (und Event Sourcing)?

Klare Grenzen, SRP.

Schreiben ist etwas anderes als Lesen. Trenne Datenstrukturen für unterschiedliche Aspekte/Zwecke.

Und was ist nun der Kern von FD?

Konzentriere dich mit SRP auf Verhalten! Aus Verhalten ergibt sich der Rest.

FD ist im Grunde Taoismus für die Codierung :-) Codiere im Hier und Jetzt. Plane nicht, sondern lass dich von Moment zu Moment vom Leben, äh, den Anforderungen tragen. Tue in jederzeit nur das unmittelbar Nötige.

Und da der Kunde Software will, die funktioniert, d.h. Verhalten zeigt, ist der Fokus des Nötigen genau darauf. Alles andere muss dem dienen, ergibt sich also. In kleinen "unmerklichen" Veränderungen.