Laravel — это не просто набор файлов и папок. Это аккуратно организованная архитектура, которая помогает вам писать понятный, поддерживаемый и масштабируемый код. Если разобраться в структуре проекта, становится ясно, что почти каждая директория существует не «для галочки», а чтобы решить конкретную задачу.

Давайте пройдёмся по стандартной структуре Laravel-проекта и параллельно разберёмся, зачем вообще нужны все эти слои.

Корень проекта

Когда вы создаёте новый проект (команда laravel new project или через Composer), в корне появляется набор папок и файлов.

Вот ключевые из них:

• app/
• bootstrap/
• config/
• database/
• public/
• resources/
• routes/
• storage/
• tests/
• vendor/
• .env
• artisan
• composer.json

Теперь разберём каждую важную часть.

Папка app/ — сердце приложения

Это основная бизнес-логика проекта.

Что здесь обычно находится:

• app/Http/
• app/Models/
• app/Providers/
• app/Console/
• app/Exceptions/

app/Http/

Здесь находится всё, что связано с HTTP-запросами:

• app/Http/Controllers/
• app/Http/Middleware/
• app/Http/Requests/

Controllers

Зачем нужны контроллеры?

Контроллер — это посредник между пользователем и логикой приложения.

Когда пользователь открывает страницу, запрос попадает в контроллер. Он:

• получает данные
• обрабатывает их
• вызывает модели
• возвращает ответ (HTML, JSON и т.д.)

Пример:

<?php

class PostController extends Controller
{
    public function index()
    {
        $posts = Post::all();
        return view('posts.index', compact('posts'));
    }
}

Контроллер отвечает за координацию, но не должен содержать сложную бизнес-логику.

Middleware

Middleware — это «фильтры» запроса.

Они решают задачи вроде:

• проверка авторизации
• проверка роли пользователя
• логирование
• ограничение частоты запросов

Проще говоря, middleware — это охрана перед входом в приложение.

Requests

Form Request классы нужны для валидации.

Вместо того чтобы писать проверку прямо в контроллере, вы создаёте отдельный класс:

<?php

class StorePostRequest extends FormRequest
{
    public function rules()
    {
        return [
            'title' => 'required|min:3',
        ];
    }
}

Это делает код чище и поддерживаемее.

app/Models/ — модели

Здесь находятся Eloquent-модели.

Зачем нужны модели?

Модель представляет таблицу базы данных и описывает:

• связи
• правила работы с данными
• бизнес-логику уровня сущности

Пример:

<?php

class Post extends Model
{
    protected $fillable = ['title', 'content'];

    public function comments()
    {
        return $this->hasMany(Comment::class);
    }
}

Модель — это способ работать с базой данных как с объектами.

app/Providers/

Service Providers — один из ключевых элементов Laravel.

Они отвечают за:

• регистрацию сервисов
• биндинг зависимостей
• настройку контейнера

Если коротко: провайдеры управляют зависимостями приложения.

routes/ — маршрутизация

• routes/web.php
• routes/api.php
• routes/console.php

Зачем нужны маршруты?

Маршрут определяет:

какой URL вызывает какой код

Пример:

Route::get('/posts', [PostController::class, 'index']);

Laravel разделяет:

• web.php — для веб-интерфейса (сессии, cookies)
• api.php — для API (обычно stateless)

Это помогает логически разделять типы запросов.

resources/ — представления и фронтенд

• resources/views/
• resources/css/
• resources/js/

Views

Файлы Blade:

resources/views/posts/index.blade.php

Зачем они нужны?

Это слой отображения. Он отвечает только за то, как данные выглядят.

Blade позволяет:

• использовать шаблоны
• подключать компоненты
• писать условия и циклы

CSS и JS

Стили и скрипты для фронтенда.

database/ — работа с БД

• database/migrations/
• database/seeders/
• database/factories/

Migrations

Миграции — это управление структурой базы данных через код.

Вместо ручного создания таблиц вы пишете:

<?php

Schema::create('posts', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->timestamps();
});

Зачем это нужно?

• контроль версий структуры БД
• возможность откатить изменения
• удобная работа в команде

Seeders

Позволяют заполнить базу тестовыми данными.

Factories

Генерируют фейковые данные для тестирования.

config/ — конфигурация

Здесь находятся файлы:

• app.php
• database.php
• cache.php
• mail.php

Зачем это нужно?

• централизованное управление настройками
• гибкость
• удобство смены окружений

public/ — точка входа

Главный файл:

public/index.php

Это вход в приложение.

Когда пользователь заходит на сайт, сервер направляет запрос сюда, а дальше Laravel берёт управление.

storage/ — служебные файлы

Содержит:

• логи
• кэш
• загруженные файлы
• сессии

Это рабочая директория приложения.

vendor/ — зависимости

Здесь лежат пакеты, установленные через Composer.

Вы не редактируете эту папку вручную.

Почему структура Laravel такая?

Laravel построен вокруг принципов:

• MVC (Model-View-Controller)
• разделение ответственности
• dependency injection
• сервис-контейнер

• Контроллер — координирует
• Модель — работает с данными
• View — отображает
• Middleware — фильтрует
• Routes — направляют

Такой подход:

• делает код читаемым
• упрощает тестирование
• помогает масштабировать проект
• облегчает работу в команде

Файл .env — настройки проекта

В корне Laravel-проекта находится файл .env. Это файл с настройками приложения. Здесь хранятся параметры, которые могут отличаться в зависимости от среды: локальный компьютер, тестовый сервер или production.

Например, внутри может быть так:

APP_NAME=MyApp
APP_ENV=local
APP_DEBUG=true

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=myapp
DB_USERNAME=root
DB_PASSWORD=secret

Здесь указано:

• в каком режиме работает приложение
• включена ли отладка
• к какой базе данных подключаться

Если ты развернёшь проект на сервере, значения будут другими — но код менять не придётся. В этом и смысл .env: отделить настройки от логики приложения.

Laravel использует эти переменные через конфигурационные файлы. Например, в config/database.php можно увидеть:

'host' => env('DB_HOST', '127.0.0.1'),

Это значит: возьми значение из .env. Если его нет — используй значение по умолчанию.

Важно: файл .env не загружают в репозиторий, потому что в нём могут быть пароли и ключи. В Git хранится только .env.example — шаблон без секретных данных.

Как структура помогает на практике

Представим, вы через год возвращаетесь к проекту.

Если структура соблюдена:

• вы быстро находите нужный код
• логика не размазана по файлам
• изменения безопаснее
• меньше «магии»

Если структура нарушена — начинается хаос.

Расширение структуры в реальных проектах

В больших проектах добавляют:

• app/Services/
• app/Repositories/
• app/DTO/
• app/Actions/
• app/Jobs/
• app/Events/

Это нужно, когда бизнес-логика становится сложной.

Например:

• Services — вынос сложной логики из контроллеров
• Repositories — абстракция работы с БД
• Jobs — очереди
• Events — событийная архитектура

Laravel из коробки даёт гибкую основу, а дальше вы масштабируете её под свои задачи.

Итог

Структура Laravel — это не случайный набор папок. Это архитектурная карта приложения.

Она нужна, чтобы:

• разделить ответственность
• упростить поддержку
• обеспечить масштабируемость
• ускорить разработку
• сделать код предсказуемым