Your repository has 47 methods. That's the problem.
Repository Pattern PHP usually ends up as a God Class with findAll, findByUser, findActiveByMonth and dozens more methods. Jardis generates a 5-stage pipeline with separate read/write paths instead, physically enforced rather than by convention.
PHP repositories keep growing. Until they become unmanageable.
The pattern is correct. Implementation fails not from lack of intent, but from missing boundaries.
Repositories turn into God Classes
Every new requirement lands as another method on the repository. findAll, findByUser, findActiveByMonth, findByStatusAndDate. After two years, the repository has 60 methods. No structure, no boundary, no end in sight.
Too tightly coupled to Eloquent or Doctrine
Laravel repositories return Eloquent collections. Symfony repositories return Doctrine entities directly. The domain is tied to the persistence layer. Swapping an ORM or adding a caching layer means rebuilding code across the entire application.
Read and write without separation
The same repository interface handles both read and write operations. Queries trigger unnecessary eager loading, commands run into caching logic that was never meant for them. Responsibilities are mixed, side effects become unpredictable.
5 Stages. Separate Paths. Zero Compromises.
Jardis does not generate generic repository classes. It generates a complete pipeline with clearly defined responsibilities at every stage.
Repository Pattern PHP as a structured pipeline
Jardis generates five clearly separated stages: Read Interface, Read Implementation, Write Interface, Write Implementation, and a Repository Gateway. Each stage has its own file, its own namespace, and its own responsibility. No mixing, no implicit dependencies.
Queries and Commands access different repositories
Read repositories are only accessible to queries. Write repositories are only reachable by commands. This separation is not a code review rule. It is the folder structure itself. A command cannot call a read repository because it cannot see it.
No ORM types in the domain layer
The generated repository interfaces work with Domain Entities, not with Eloquent models or Doctrine entities. The persistence layer is replaceable. Switching from MySQL to PostgreSQL or adding a Redis cache layer does not touch the domain.
See what three files turn into.
Three definition files in, a complete bounded context out. Browse the generated 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
Why the pipeline beats a single repository.
Because a repository that can do everything eventually communicates nothing clearly.
Every data access has a defined path
Read operations go through read repositories, writes through write repositories. The entry point is unambiguous. Side effects from misused repositories disappear.
Repositories do not grow without limit
The 5-stage pipeline has clear boundaries per stage. New queries go into the read repository, new writes into the write repository. No single repository accumulates all methods of an aggregate.
ORM changes do not touch the domain
Repository interfaces work with Domain Entities. Eloquent, Doctrine, raw PDO: the implementation is isolated. A caching layer can be added without touching domain logic.
Repository Pattern PHP without God Classes or convention debates?
Join the WaitlistStructure costs less than chaos.
Try Jardis 7 Days Free
Point Jardis at your real domain. Discovery, structure, and your first platform build.
Join WaitlistThe complete DDD architecture with all classes and contracts. Your team ships features, not infrastructure.
Join WaitlistThe complete business logic with handlers, validation, and pipelines. What used to be a sprint is now a build.
Join WaitlistMore than 20 Platform Builds per month?
Let's talkBe there when Jardis launches.
Sign up. You'll get access as soon as we go live. Including a free trial.
Curious how Jardis works?
Discover JardisFrequently Asked Questions
Answers about the repository pipeline with Jardis.
Jardis generates five stages per aggregate: Read Interface, Read Implementation, Write Interface, Write Implementation, and a Repository Gateway that consolidates the access points. Each stage is a separate PHP class in its own namespace. The structure is identical across every Bounded Context.