Dein Repository hat 47 Methoden. Das ist das Problem.
Repository Pattern PHP endet meist als God Class mit findAll, findByUser, findActiveByMonth und Dutzenden weiteren Methoden. Jardis erzeugt stattdessen eine 4-Stufen-Pipeline pro Aggregate: Query, Transform, Validate, Persist. Jede Stufe mit klarer Verantwortung, strukturell erzwungen statt per Konvention.
PHP-Repositories wachsen. Bis sie unkontrollierbar sind.
Das Pattern ist richtig. Die Umsetzung scheitert nicht an Absicht, sondern an fehlenden Grenzen.
Repositories werden zu God Classes
Jede neue Anforderung landet als neue Methode im Repository. findAll, findByUser, findActiveByMonth, findByStatusAndDate. Nach zwei Jahren hat das Repository 60 Methoden. Keine Struktur, keine Grenze, kein Ende.
Zu eng an Eloquent oder Doctrine gebunden
Laravel-Repositories geben Eloquent-Collections zurück. Symfony-Repositories liefern Doctrine-Entities direkt. Die Domain ist an die Persistence-Schicht gekoppelt. Ein ORM-Wechsel oder ein Caching-Layer bedeutet einen Umbau quer durch die gesamte Anwendung.
Read und Write ohne Trennung
Dasselbe Repository-Interface bedient sowohl lesende als auch schreibende Operationen. Queries laden unnötig eager, Commands treffen auf Caching-Logik, die nicht für sie gedacht war. Die Verantwortlichkeiten sind vermischt, die Seiteneffekte unvorhersehbar.
4 Stufen. Klare Verantwortung. Keine God Class.
Jardis erzeugt keine generischen Repository-Klassen. Es erzeugt eine vollständige Pipeline mit klar definierten Verantwortlichkeiten auf jeder Stufe.
Repository Pattern PHP als strukturierte Pipeline
Jardis erzeugt vier klar getrennte Stufen pro Aggregate: Query, Transform, Validate und Persist. Jede Stufe hat eine eigene Datei, einen eigenen Namespace und genau eine Verantwortung. Datenzugriff ist eine strukturierte Pipeline, kein Repository mit Dutzenden Methoden.
Lesen und Schreiben laufen über verschiedene Stufen
Die Query-Stufe ist der Lesepfad, Persist der Schreibpfad. Zusammen mit der CQRS-Trennung von Commands und Queries laufen lesende und schreibende Zugriffe nie durch dieselbe God-Class-Methode. Die Trennung steckt in der Struktur, nicht in einer Code-Review-Regel.
Kein ORM-Typ in der Domain-Schicht
Die erzeugten Repository-Interfaces arbeiten mit Domain Entities, nicht mit Eloquent-Models oder Doctrine-Entities. Die Persistence-Schicht ist austauschbar. Ein Wechsel von MySQL auf PostgreSQL oder das Einziehen eines Redis-Caches berührt die Domain nicht.
Warum die Pipeline besser ist als ein einzelnes Repository.
Weil ein Repository, das alles kann, auf Dauer nichts mehr klar kommuniziert.
Jeder Datenzugriff hat einen definierten Pfad
Lesende Operationen gehen über die Query-Stufe, schreibende über Persist. Der Einstiegspunkt ist eindeutig. Seiteneffekte durch falsch verwendete Repositories entfallen.
Repositories wachsen nicht unbegrenzt
Die 4-Stufen-Pipeline hat klare Grenzen pro Stufe. Datenzugriff folgt der Abfolge Query, Transform, Validate, Persist, statt sich als weitere findBy-Methode anzusammeln. Kein einzelnes Repository akkumuliert alle Methoden eines Aggregates.
ORM-Wechsel berührt die Domain nicht
Repository-Interfaces arbeiten mit Domain Entities. Eloquent, Doctrine, raw PDO: die Implementierung ist isoliert. Ein Caching-Layer lässt sich einziehen, ohne die Domain-Logik anzufassen.
Repository Pattern PHP ohne God Classes und ohne Konventions-Diskussionen?
Auf die WaitlistHäufige Fragen
Antworten zur Repository Pipeline mit Jardis.
Jardis erzeugt vier Stufen pro Aggregate: Query, Transform, Validate und Persist. Query baut und führt die Datenabfrage aus, Transform mappt zwischen Datenbank-Rohdaten und typisierten Domain-Objekten, Validate prüft die Daten gegen die Aggregat-Regeln, Persist schreibt die Änderungen in die Datenbank. Jede Stufe ist eine eigene PHP-Klasse in einem eigenen Namespace, identisch für jeden Bounded Context.