Beitrag erstellt am: 26.04.18
Martin Fowler weist in seinem Artikel zu CQRS
ausdrücklich darauf hin, dass CQRS nicht in jedem Fall die richtige Wahl ist. Seiner Meinung nach gibt es viele Systeme, die mit dem klassischen CRUD-Ansatz gut bedient sind.
Greg Young hält CQRS unabdingbar für Event Sourcing. Denn der Event Store bietet nur eine schmale Abfrage-Schnittstelle, die es lediglich ermöglicht, einen Strom von Ereignissen zu lesen.
Ein Aspekt scheint mir bezüglich CQRS bedeutsam, den beide nicht explizit diskutieren: Aggregate im DDD und das Thema der Navigierbarkeit entlang von Objektbäumen. Evans und auch Vaughn halten explizit fest, dass das Aggregat einen transaktionalen Konsistenzrahmen formt, um die Daten eines Objektverbunds unter Wahrung der geltenden Invarianten zu speichern. Das Navigieren innerhalb des Domänenmodells ist ausdrücklich nicht Aufgabe des Aggregats.
Und hier kommen nun CRUD, O/R-Mapping und letztlich eben auch CQRS ins Spiel: Mit einem klassischen O/R-Mapper wie Hibernate sind wir ohne eine klare Trennung der Lese- und Schreibmodelle gezwungen, unsere Aggregate mit Aspekten für das Navigieren entlang der im unterliegenden Datenmodell abgebildeten Relationen zu überfrachten bzw. zu belasten.
Das Problem zeigt sich immer dort, wo wir im Aggregat grundsätzlich eine schwache Referenz auf ein verbundenes Objekt führen könnten, weil es reicht, dieses Objekt über seine Id zu kennen: Wenn wir die Lesesichten auf den Aggregaten des Domain-Layers basieren, dann müssen wir das Aggregat zwangsläufig mit Leseaspekten versehen, um z.B. das klassische N+1-Problem zu vermeiden, die Nutzung einer schwachen Referenz ist nicht möglich. Das Aggregat verliert so zwangsläufig seinen Nutzen als primäres Instrument für das kontrollierte und transaktionale Speichern von Daten. Je nach Komplexität des abzubildenden bzw. zu mappenden Datenmodells sind wir gezwungen, unnötig grosse Aggregate zu modellieren; das erhöht die Gefahr für Inkonsistenzen und das Entstehen von überlappenden Aggregaten. Im Extremfall wird das Domänenmodell zu einer glorifizierten Repräsentation des darunter liegenden Datenmodells, das wenig mehr als ein CRUD-orientiertes Objektmodell formt.
Greg Young hält CQRS unabdingbar für Event Sourcing. Denn der Event Store bietet nur eine schmale Abfrage-Schnittstelle, die es lediglich ermöglicht, einen Strom von Ereignissen zu lesen.
Ein Aspekt scheint mir bezüglich CQRS bedeutsam, den beide nicht explizit diskutieren: Aggregate im DDD und das Thema der Navigierbarkeit entlang von Objektbäumen. Evans und auch Vaughn halten explizit fest, dass das Aggregat einen transaktionalen Konsistenzrahmen formt, um die Daten eines Objektverbunds unter Wahrung der geltenden Invarianten zu speichern. Das Navigieren innerhalb des Domänenmodells ist ausdrücklich nicht Aufgabe des Aggregats.
Und hier kommen nun CRUD, O/R-Mapping und letztlich eben auch CQRS ins Spiel: Mit einem klassischen O/R-Mapper wie Hibernate sind wir ohne eine klare Trennung der Lese- und Schreibmodelle gezwungen, unsere Aggregate mit Aspekten für das Navigieren entlang der im unterliegenden Datenmodell abgebildeten Relationen zu überfrachten bzw. zu belasten.
Das Problem zeigt sich immer dort, wo wir im Aggregat grundsätzlich eine schwache Referenz auf ein verbundenes Objekt führen könnten, weil es reicht, dieses Objekt über seine Id zu kennen: Wenn wir die Lesesichten auf den Aggregaten des Domain-Layers basieren, dann müssen wir das Aggregat zwangsläufig mit Leseaspekten versehen, um z.B. das klassische N+1-Problem zu vermeiden, die Nutzung einer schwachen Referenz ist nicht möglich. Das Aggregat verliert so zwangsläufig seinen Nutzen als primäres Instrument für das kontrollierte und transaktionale Speichern von Daten. Je nach Komplexität des abzubildenden bzw. zu mappenden Datenmodells sind wir gezwungen, unnötig grosse Aggregate zu modellieren; das erhöht die Gefahr für Inkonsistenzen und das Entstehen von überlappenden Aggregaten. Im Extremfall wird das Domänenmodell zu einer glorifizierten Repräsentation des darunter liegenden Datenmodells, das wenig mehr als ein CRUD-orientiertes Objektmodell formt.