CQRS richtig implementieren. In PHP.
Command Query Responsibility Segregation korrekt umzusetzen bedeutet Wochen manueller Infrastruktur-Arbeit. Jardis erzeugt Commands, Queries, Handler und Response-Objekte als getrennte, typisierte DTOs, strukturell erzwungen statt per Konvention.
Alle wollen CQRS, kaum jemand setzt es in PHP korrekt um.
Das Pattern klingt einfach. Die dauerhafte, konsistente Umsetzung in realen Projekten ist es nicht.
Read und Write vermischen sich
Es beginnt mit einem Query, der nebenbei Daten schreibt. Oder einem Command, der ein Ergebnis zurückgibt. Nach ein paar Sprints ist die Trennung nur noch Theorie. Repositories bedienen Read und Write gleichermaßen, DTOs gibt es keine.
Jeder Handler sieht anders aus
Jeder Entwickler implementiert Commands und Queries anders. Mal mit eigenem Handler, mal inline im Controller. Mal mit Response-Objekt, mal mit Array-Return. Kein einheitliches Pattern, keine Vorhersagbarkeit.
Wochen für die Infrastruktur
Bevor das Team die erste Business-Logik schreibt, vergehen Wochen mit Command-Bus-Setup, Query-Bus-Konfiguration, DTO-Basisklassen und Handler-Registrierung. Wiederkehrende Infrastruktur-Arbeit, die in jedem PHP-Projekt identisch aussieht und trotzdem jedes Mal manuell passiert.
Wie Jardis CQRS implementiert.
Nicht als optionale Konvention, sondern als physische Trennung in separaten Namespaces.
Typisierte Commands mit eigenen Handlern
Jardis erzeugt für jeden Schreibvorgang ein CommandDTO und einen dedizierten CommandHandler. Commands leben in einem eigenen Namespace innerhalb des Bounded Context. Keine Vermischung mit Queries, keine generischen Handler, keine Abkürzungen.
Read-Seite als eigenständiger Pfad
Jede Abfrage bekommt ein QueryDTO, einen QueryHandler und ein typisiertes Response-Objekt. Die 5-Stage Repository Pipeline trennt Read- und Write-Pfade auf Repository-Ebene. Queries greifen nur auf Read-Repositories zu, Commands nur auf Write-Repositories.
CQRS PHP implementieren ohne Erosion
Commands und Queries leben in separaten Namespaces innerhalb jedes Bounded Context. Diese Trennung ist keine Guideline, die man ignorieren kann. Sie ist die Ordnerstruktur selbst. Neue Teammitglieder sehen sofort, was ein Command ist und was eine Query.
Warum Teams mit Jardis auf CQRS setzen.
Weil CQRS nicht am Verständnis scheitert, sondern an der konsequenten Umsetzung.
Jeder Vorgang hat genau einen Pfad
Commands schreiben, Queries lesen. Kein Handler, der beides tut. Kein Repository, das Read und Write vermischt. Die Trennung ist nicht optional, sie ist die Struktur.
CQRS-Infrastruktur ab dem ersten Builder-Run
Schema definieren, Builder starten. CommandDTOs, QueryDTOs, Handler und Response-Objekte stehen sofort. Die komplette CQRS-Infrastruktur eines neuen Bounded Context ist produktionsreif. Keine manuelle Bus-Konfiguration, keine Basisklassen-Diskussionen.
Commands und Queries folgen einem Standard
Ob drei oder dreißig Contexts: Commands und Queries folgen demselben Aufbau. Neue Teammitglieder verstehen einen Context und kennen alle. Keine Sonderlösungen, keine historisch gewachsenen Abweichungen.
CQRS als Standard, nicht als Wunschdenken?
Auf die WaitlistHäufige Fragen
Antworten zu CQRS mit Jardis.
Pro Bounded Context erzeugt Jardis typisierte CommandDTOs mit dedizierten CommandHandlern und QueryDTOs mit QueryHandlern und Response-Objekten in PHP. Commands und Queries leben in separaten Namespaces. Die Repository Pipeline trennt Read- und Write-Pfade physisch, sodass Queries nur Read-Repositories erreichen.