Command Query Responsibility Segregation: Drei Implementierungsansätze für bessere Softwarearchitektur

Die Welt der Software-Entwicklung hat sich in den letzten Jahren drastisch verändert. Während Während Domain-Driven Design (DDD) vor über zwei Jahrzehnten als revolutionärer Ansatz eingeführt wurde, zeigt die Praxis heute neue Herausforderungen auf. CQRS (Command Query Responsibility Segregation) bietet eine elegante Lösung für diese Komplexitäten und etabliert sich als wichtiger Architektur-Ansatz in der modernen Software-Entwicklung.

Was ist CQRS und warum ist es wichtig?

CQRS steht für Command Query Responsibility Segregation und beschreibt ein Architekturmuster, das die Verantwortlichkeiten für das Lesen und Schreiben von Daten strikt trennt. Dieses Konzept baut auf dem von Bertrand Meyer in den 1980er Jahren formulierten Command-Query-Separation-Prinzip auf, wurde aber als eigenständiges Architekturmuster von Greg Young weiterentwickelt: Jede Aktion in der Software kann entweder ein Command (Befehl) oder eine Query (Abfrage) sein, aber niemals beides gleichzeitig.

Die Grundprinzipien von CQRS

Ein Command wird definiert als eine Aktion, die den Zustand des Systems verändert, jedoch keine Daten zurückgibt. Eine Query hingegen ist eine Aktion, die Daten liest und zurückgibt, ohne den Systemzustand zu verändern. Diese klare Trennung ermöglicht es Entwicklern, beide Verantwortlichkeiten getrennt und optimiert zu implementieren.

Die Herausforderungen traditioneller Architekturen

Das Problem der All-Encompassing Object Models

Traditionelle Domain-Driven Design Ansätze versuchen oft, ein einziges, umfassendes Objektmodell zu erstellen, das alle funktionalen und nicht-funktionalen Aspekte eines Software-Systems abdeckt. In der Praxis erweist sich dies jedoch als schwieriger als ursprünglich angenommen.

Betrachten wir das Beispiel einer Klasse für ein Sportspiel: Eine verhaltensreiche Klasse mit Methoden wie Start(), Finish() und Goal() eignet sich perfekt für Szenarien, in denen der Systemzustand verändert wird. Für einfache Abfrage-Szenarien, bei denen nur der aktuelle Spielstand angezeigt werden soll, ist jedoch eine einfachere Data Transfer Object-Klasse besser geeignet.

Kompromisse bei monolithischen Ansätzen

In traditionellen Architekturen führt die Verwendung einer einzigen Klasse für Commands und Queries unweigerlich zu Kompromissen:

• Verhaltensreiche Klassen benötigen Anpassungen für die Persistierung via O/RM
• Das Risiko der Exposition unerwünschter Funktionalität in der Präsentationsschicht
• Fehlende Implementierung von Geschäftsregeln in einfachen DTOs
• Potenzial für inkonsistente Instanzen durch öffentliche Getter und Setter

Die drei Implementierungsansätze von CQRS

Einfaches CQRS: Der Einstieg in die getrennte Architektur

Einfaches CQRS bildet die Grundlage und eignet sich besonders für bestehende CRUD-Anwendungen. Hier wird die Anwendungsarchitektur so angepasst, dass anstelle eines monolithischen Blocks für Datenbankzugriffe zwei getrennte Blöcke entstehen:

Command Stack Implementierung

• Verwendung des besten passenden Patterns für die jeweilige Situation
• Integration bestehenden Codes ohne Aufopferung bewährter Lösungen
• Flexibilität bei der Wahl der Geschäftslogik-Implementierung (Domain Model, Table Module, Transaction Script)

Query Stack Optimierung

• Einsatz der optimalen Datenzugriffstechnologie
• Verwendung von LINQ für Datenabfragen und Materialisierung in geeignete View-Models für die Datenbindung
• Implementierung schreibgeschützter Wrapper für Entity Framework DbContext

CQRS mit getrennten Datenmodellen: Unterschiedliche Datenformate für Commands und Queries

CQRS mit getrennten Datenmodellen kommt zum Einsatz, wenn das natürliche Format der durch Commands verarbeiteten Daten erheblich von der idealen Darstellung für Benutzer abweicht. Diese Variante nutzt separate Datenbanken für Commands und Queries.

Synchronisationsmöglichkeiten

Die Herausforderung bei separaten Datenspeichern liegt in der Synchronisation:

• Synchron: Synchronisation als Teil der Command-Transaktion
• Asynchron: SSynchronisation außerhalb der Command-Transaktion mit geringer Verzögerung
• Geplant: Periodische Synchronisation in definierten Intervallen
• On-Demand: Synchronisation nur bei Bedarf

Umgang mit veralteten Daten

Je nach Synchronisationsansatz ergeben sich unterschiedliche Toleranzen für veraltete Daten - von vollständiger Aktualität bis hin zu akzeptablen Verzögerungen von Sekunden, Stunden oder sogar Tagen.

CQRS mit Event Sourcing: Message-basierte Geschäftslogik

CQRS mit Event Sourcing stellt die ausgefeilteste Variante dar und basiert auf einer message-basierten Implementierung der Geschäftsprozesse. Diese Architektur nutzt einen Bus als zentrales Kommunikationselement.

Kernkomponenten der Deluxe-Architektur

Der Message Bus

Der Bus fungiert als gemeinsamer Kommunikationskanal und verwaltet:

• Eine Sammlung bekannter Saga-Typen
• Laufende Saga-Instanzen
• Registrierte Handler

Sagas und Handler

• Sagas: Zustandsbehaftete, persistierbare Prozesse mit Zugriff auf den Bus
• Handler: Einfache, einmalige Ausführer für spezifische Messages

Message-Typen

Messages werden in zwei Kategorien unterteilt:

• Commands: Imperative Aktionen (z.B. "SubmitOrderCommand")
• Events: Benachrichtigungen über vergangene Ereignisse (z.B. "OrderCreated")

Praktische Implementierung in ASP.NET MVC

Request-Verarbeitung in CQRS

Bei der Implementierung in ASP.NET MVC erfolgt die Unterscheidung zwischen Commands und Queries bereits auf Controller-Ebene:

• HttpGet-Requests werden als Queries behandelt
• HttpPost-Requests werden als Commands verarbeitet

Nach der Ausführung eines Commands wird typischerweise eine Weiterleitung zu einer Anzeige-Action durchgeführt, die dann entsprechende Queries ausführt, was das Post-Redirect-Get-Pattern implementiert und störende Browser-Dialoge bei Seitenaktualisierungen verhindert.

Event Sourcing Integration

CQRS mit Event Sourcing ermöglicht die nahtlose Integration von Event Sourcing:

• Business Events werden als echter Teil der Datenquelle behandelt
• Events können vor der Weiterleitung an Listener im Event Store persistiert werden
• Vollständige Nachverfolgbarkeit aller Systemänderungen

Vorteile der CQRS-Architektur

Entwicklungsvorteile

• Parallele Entwicklung: Getrennte Stacks ermöglichen unabhängige Entwicklung
• Technologie-Flexibilität: Optimale Technologiewahl für jeden Stack ohne Einschränkungen
• Skill-Wiederverwertung: Bestehende Fähigkeiten und Investitionen bleiben nutzbar

Performance und Skalierbarkeit

• Stack-spezifische Optimierung: Jeder Stack kann für seinen Anwendungsfall optimiert werden
• Skalierungspotenzial: Grundlage für horizontale Skalierung
• Reduzierte Komplexität: Einfacheres Design durch getrennte Verantwortlichkeiten

Wartbarkeit und Erweiterbarkeit

• Begrenzte Abhängigkeiten: Weniger gemeinsame Kopplungen zwischen Commands und Queries
• Einfaches Refactoring: Änderungen wirken sich nur auf den betroffenen Stack aus
• Modulare Erweiterungen: Neue Features durch zusätzliche Handler oder Sagas

Wann sollten Sie CQRS einsetzen?

Ideale Anwendungsszenarien

CQRS eignet sich besonders für:

• Kollaborative Systeme mit hohem Traffic und Skalierungsanforderungen
• Event-basierte Anwendungen wie Live-Scoring-Systeme
• Komplexe Geschäftsprozesse mit unterschiedlichen Lese- und Schreibanforderungen
• Systeme mit hohen Performance-Anforderungen für Abfragen

Auch für einfache Anwendungen geeignet

Entgegen der weit verbreiteten Meinung funktioniert CQRS auch bei einfachen CRUD-Anwendungen und bietet dort bereits Vorteile in Bezug auf Klarheit und Wartbarkeit.

Herausforderungen und Überlegungen

Infrastruktur-Anforderungen

• Erhöhte Komplexität: Mehr Infrastruktur-Code erforderlich
• Synchronisation: Management der Datenkonsistenz zwischen Stacks
• Message-Bus: Implementation oder Integration bestehender Lösungen

Verfügbare Tools und Frameworks

Für die Implementation von CQRS mit Event Sourcing stehen verschiedene Frameworks zur Verfügung:

• NServiceBus von Particular Software
• Rebus von Rebus-org
• MassTransit von Pandora

Fazit

CQRS stellt eine evolutionäre Weiterentwicklung traditioneller Architekturansätze dar und bietet konkrete Lösungen für die Herausforderungen moderner Software-Entwicklung. Die drei vorgestellten Implementierungsansätze - Regular, Premium und Deluxe - ermöglichen es Entwicklern, den optimalen Komplexitätsgrad für ihre spezifischen Anforderungen zu wählen.

Die Trennung von Commands und Queries führt zu klareren, wartbareren und skalierbaren Systemen. Während Einfaches CQRS einen sanften Einstieg für bestehende Anwendungen bietet, ermöglichen Premium und Deluxe die Realisierung hochperformanter, event-getriebener Architekturen.

Die Investition in CQRS zahlt sich besonders bei Systemen aus, die über die Zeit wachsen und sich entwickeln müssen. Die resultierende Flexibilität und Erweiterbarkeit rechtfertigen den initialen Mehraufwand und schaffen die Grundlage für zukunftsfähige Software-Architekturen.

Häufig gestellte Fragen (FAQs)

Ist CQRS nur für komplexe Anwendungen geeignet?

Nein, CQRS funktioniert auch bei einfachen CRUD-Anwendungen sehr gut. Bereits Einfaches CQRS bietet Vorteile in Bezug auf Klarheit und Wartbarkeit, ohne die Komplexität erheblich zu steigern.

Wie gehe ich mit der Datenkonsistenz zwischen Command- und Query-Stack um?

Die Konsistenz hängt vom gewählten Synchronisationsansatz ab. Während synchrone Synchronisation sofortige Konsistenz gewährleistet, bieten asynchrone Ansätze bessere Performance bei "eventually consistent" Daten. Die Wahl hängt von den spezifischen Geschäftsanforderungen ab.

Benötige ich zwingend einen kommerziellen Message-Bus für CQRS mit Event Sourcing?

Nein, Sie können durchaus Ihren eigenen Bus implementieren. Kommerzielle oder Open-Source-Lösungen bieten jedoch zusätzliche Features wie Persistierung, Queuing und erweiterte Routing-Funktionalitäten, die bei wachsenden Anforderungen hilfreich sind.