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 generiert 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 generiert keine generischen Repository-Klassen. Es generiert eine vollständige Pipeline mit klar definierten Verantwortlichkeiten auf jeder Stufe.
Repository Pattern PHP als strukturierte Pipeline
Jardis generiert 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 generierten 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.
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 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 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 zur Repository Pipeline mit Jardis.
Jardis generiert 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.