LaravelPHPModulesArchitectureBackendClean Code
Laravel Module Structure Explained: Keep Large Apps Clean
A practical guide to Laravel module architecture — folder layout, providers, routes, and boundaries that keep features independent as your app grows.
Laravel Module Architecture: The Folder Structure That Saved My Sanity
Every Laravel project starts the same way.
You create a new project. Folders look clean. You can find any file in a few seconds. It feels like this setup will work forever.
Then the project grows.
A few features become ten. Ten become twenty. Suddenly, app/Http/Controllers is full. Services are all over the place. To understand one feature, you have to open many folders.
I’ve been there more than once.
After working on a few large Laravel apps, I saw the real issue. It wasn’t Laravel. It was how I organized the code.
That’s when I started using a modular structure.
What is a module?
This is not microservices.
This is not splitting your app into many repositories.
It means one Laravel project, but each feature has its own folder.
For example, in a Blog feature, you keep related files together:
Controllers
Models
Services
Policies
Migrations
Routes
Tests
You do the same for Billing, Users, Orders, and other big features.
So you stop grouping files by type. You group them by feature.
I like this better because I always know where to look when I need to change something.
Why I like this approach
The main benefit is not speed.
It’s clarity.
When a new developer joins, they don’t have to search the whole app to understand Blog. They open the Blog module, and everything is there.
Refactoring is also easier. You work inside one feature instead of jumping across half the project.
As the app gets bigger, this separation helps even more.
The idea is simple
I treat each module like a small Laravel app.
Each module can have its own:
Routes
Controllers
Models
Services
Events
Policies
Jobs
Migrations
Tests
The request flow stays the same:
Request
↓
Route
↓
Controller
↓
Service
↓
Model
↓
Database
If you already know Laravel, you don’t need to learn a new way of working. You just keep related files closer.
The folder structure I usually use
This is what I use for medium and large Laravel projects:
Modules/
│
├── Blog/
│ ├── App/
│ │ ├── Http/
│ │ │ └── Controllers/
│ │ ├── Models/
│ │ ├── Services/
│ │ ├── Data/
│ │ ├── Policies/
│ │ ├── Events/
│ │ ├── Listeners/
│ │ ├── Jobs/
│ │ └── Providers/
│ │
│ ├── Database/
│ │ ├── Migrations/
│ │ ├── Seeders/
│ │ └── Factories/
│ │
│ ├── routes/
│ │ ├── api.php
│ │ └── web.php
│ │
│ ├── config/
│ ├── resources/
│ │ └── views/
│ ├── tests/
│ └── module.json
Is this the only way?
No.
For small projects, the default Laravel structure is fine.
But when the app grows and more people work on it, feature-based modules make life easier. The code is simpler to find, simpler to update, and less scary after six months.
In the next part, I’ll show how to build this structure from scratch and how to make Laravel load modules automatically.
Comments
0 comments · new ones appear after approval
No comments yet. Be the first to share your thoughts.
Leave a comment
Your comment will be reviewed before it appears.