8.3 Laravel Application Structure
Laravel applications follow the framework’s conventions while organizing business logic in a way that supports long-term maintainability and testing. We use Laravel’s built-in directory structure as the foundation while adding organizational patterns that serve our specific needs.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
laravel-project/
├── app/
│ ├── Http/
│ │ ├── Controllers/
│ │ ├── Middleware/
│ │ ├── Requests/
│ │ └── Resources/
│ ├── Models/
│ ├── Services/
│ ├── Repositories/
│ ├── Events/
│ ├── Listeners/
│ └── Console/
├── resources/
│ ├── views/
│ │ ├── components/
│ │ ├── layouts/
│ │ └── pages/
│ ├── css/
│ ├── js/
│ └── lang/
├── database/
│ ├── migrations/
│ ├── factories/
│ └── seeders/
├── tests/
│ ├── Feature/
│ └── Unit/
├── routes/
├── storage/
├── public/
├── config/
├── composer.json
├── package.json
└── README.md
Service classes contain business logic that doesn’t belong in controllers or models, providing a clean separation of concerns. Repository classes abstract database interactions when needed, particularly for complex queries or when multiple models are involved.
The resources/views/components directory contains reusable Blade components that can be used across different pages and layouts, similar to our approach with WordPress template parts.