Your project screams Laravel. Not your domain.
Clean Architecture PHP means the business logic does not know the framework exists. Jardis generates Robert C. Martin's concentric circles as a physical folder structure, not an architecture recommendation.
Clean Architecture PHP fails not at the concept level, but at execution.
The Dependency Rule takes 20 minutes to explain. Holding it consistently against deadline pressure, frameworks, and changing teams is a different problem.
Framework logic infiltrates the domain
An Eloquent model here, a Laravel request object there. Every shortcut pulls framework dependencies into the innermost circles. After a year, the domain cannot be tested without Laravel.
The Dependency Rule lives in conversation, not in code
Everyone knows the rule: dependencies point inward. But under sprint pressure, the handler reaches directly into the repository object, the use case imports the mailer. The rule lives in Confluence, not in the codebase.
Screaming Architecture screams the wrong thing
Robert C. Martin's concept is precise: the folder structure should scream the domain, not the framework. But the first thing new developers see is `app/Http`, `app/Models`, `app/Jobs`. The framework screams. The domain whispers.
Dependency Rule enforced. Not recommended.
Jardis generates Clean Architecture PHP as a physical file structure. What must point inward cannot point outward.
Dependencies pointing inward, by construction
Jardis generates the 3-layer entity hierarchy (Domain Entity, Aggregate Entity, BoundedContext Layer) in namespaces that structurally disallow framework dependencies. Use cases know only domain objects. Infrastructure implements interfaces that the domain defines. Not the other way around.
The folder structure screams the domain
For every Bounded Context, Jardis generates a directory structure that starts with the domain name, not the framework concept. Commands, queries, domain events, entities: every concept has its place in the hierarchy. A developer opening the code immediately understands what they are dealing with.
Laravel or Symfony: the domain does not notice
Jardis is framework-agnostic. Whether Laravel, Symfony, or another PHP framework: the generated domain and use case layers have no framework imports. Infrastructure adapters couple the outer circles to the framework. The inner circles stay clean.
Why Teams Choose Jardis for Clean Architecture PHP.
Because the Dependency Rule cannot be enforced through code reviews. It has to be the structure.
Business logic testable without the framework
Use cases and domain objects have no framework dependencies. Unit tests need no Laravel bootstrap overhead. Fast, isolated tests for the logic that actually matters.
Swap the framework, keep the domain
The inner circles do not know the framework. Infrastructure adapters handle the outer coupling. When the framework changes, the infrastructure layer changes, not the business logic.
New features without architecture debates
Where a new feature belongs is defined by the structure. No debate: controller or use case? Repository or domain service? The structure answers that.
Clean Architecture PHP as structure, not as intention?
Join the WaitlistFrequently Asked Questions
Answers about Clean Architecture PHP with Jardis.
Hexagonal Architecture focuses on Ports & Adapters and physical layer separation. Clean Architecture focuses on the Dependency Rule: dependencies point inward, never outward. Jardis enforces both, but the narratives are distinct: this page is about framework independence and Screaming Architecture.