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 5-Stage Pipeline mit getrennten Read/Write-Pfaden, physisch 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.
5 Stages. Getrennte Pfade. Null Kompromisse.
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 fünf klar getrennte Stufen: Read Interface, Read Implementation, Write Interface, Write Implementation und ein Repository Gateway. Jede Stufe hat eine eigene Datei, einen eigenen Namespace und eine eigene Verantwortlichkeit. Keine Vermischung, keine impliziten Abhängigkeiten.
Queries und Commands greifen auf verschiedene Repositories zu
Read-Repositories sind nur für Queries zugänglich. Write-Repositories sind nur für Commands erreichbar. Diese Trennung ist nicht eine Regel im Code-Review. Sie ist die Ordnerstruktur selbst. Ein Command kann kein Read-Repository aufrufen, weil es ihn nicht sieht.
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 durch Read-Repositories, schreibende durch Write-Repositories. Der Einstiegspunkt ist eindeutig. Seiteneffekte durch falsch verwendete Repositories entfallen.
Repositories wachsen nicht unbegrenzt
Die 5-Stage Pipeline hat klare Grenzen pro Stufe. Neue Abfragen landen im Read-Repository, neue Schreibvorgänge im Write-Repository. 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 fünf Stufen pro Aggregate: Read Interface, Read Implementation, Write Interface, Write Implementation und ein Repository Gateway, das die Zugriffspunkte zusammenführt. Jede Stufe ist eine eigene PHP-Klasse in einem eigenen Namespace. Die Struktur ist identisch für jeden Bounded Context.