CQRS richtig implementieren. In PHP.
Command Query Responsibility Segregation korrekt umzusetzen bedeutet Wochen manueller Infrastruktur-Arbeit. Jardis generiert 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 generiert 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.
Sieh selbst, was aus drei Dateien entsteht.
Drei Definitionsdateien rein, ein kompletter Bounded Context raus. Klick dich durch den generierten Code.
# Database Schema — Sales Bounded Context
# This file defines the persistent storage structure.
schema:
domain: ECommerce
boundedContext: Sales
tables:
order:
columns:
id:
type: integer
primary: true
autoIncrement: true
public_id:
type: uuid7
unique: true
customer_email:
type: string
length: 255
status:
type: string
length: 32
default: "draft"
total_amount:
type: integer
currency:
type: string
length: 3
default: "EUR"
created_at:
type: datetime
updated_at:
type: datetime
nullable: true
order_item:
columns:
id:
type: integer
primary: true
autoIncrement: true
order_id:
type: integer
foreignKey:
table: order
column: id
onDelete: cascade
product_name:
type: string
length: 255
sku:
type: string
length: 64
quantity:
type: integer
unit_price:
type: integer
line_total:
type: integer
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 WaitlistStruktur kostet weniger als Chaos.
Teste Jardis 7 Tage kostenlos
Lass Jardis an deiner echten Domäne los. Discovery, Struktur und dein erster Platform Build.
Join WaitlistDie komplette DDD-Architektur mit allen Klassen und Contracts. Dein Team schreibt Features, nicht Infrastruktur.
Join WaitlistDie komplette Business-Logik mit Handlern, Validierung und Pipelines. Was früher ein Sprint war, ist jetzt ein Build.
Join WaitlistMehr als 20 Platform Builds pro Monat?
Lass uns sprechenSei dabei, wenn Jardis startet.
Trag dich ein. Du bekommst Zugang, sobald wir live gehen. Inklusive kostenlosem Trial.
Neugierig, wie Jardis funktioniert?
Jardis entdeckenHäufige Fragen
Antworten zu CQRS mit Jardis.
Pro Bounded Context generiert 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.