Laravel здається простим, поки проєкт маленький. Але як тільки з’являються десятки сторінок, ролі, фільтри, медіа і різні стани публікації, без стандарту структура починає розповзатися. Новачок тоді “ліпить” логіку в контролер, підтягує SQL у Blade, дублює шматки коду і поступово перетворює систему на болото. Мінімальний стандарт потрібен саме для того, щоб кожна нова фіча додавалась прогнозовано і не ламала те, що вже працює.
Почнемо з головної ідеї: Laravel — це конвеєр обробки запиту. Запит приходить у public/index.php, далі проходить через middleware, потрапляє в маршрути, потім у контролер, далі в сервісну/доменно-логічну частину, звертається до моделей та бази, і повертається назад у відповідь як HTML або JSON. Якщо ти розумієш цей шлях, ти завжди знаєш, де шукати проблему і куди правильно додавати нову логіку.
Основний “каркас” проєкту — папка app. Там живе твій код: контролери, моделі, сервіси, middleware, політики, консольні команди. Правило просте: усе, що є “логікою продукту”, повинно бути в app, а не в resources чи в випадкових helper-файлах. Якщо новачок не засвоїть цього правила, він почне розкидати код де попало, і через місяць ніхто не буде розуміти, як воно працює.
Маршрути в Laravel лежать у routes. Найчастіше ти працюєш з routes/web.php для HTML-сторінок і routes/api.php для API. Мінімальний стандарт тут такий: маршрути групуються за доменом і захищаються middleware на рівні групи. Ти не пишеш 200 окремих маршрутів у один файл без структури, ти робиш групи з префіксом, іменами й доступами, щоб читати було легко.
Коли ти додаєш маршрут, ти маєш одразу думати про три речі. Перша — URL і HTTP-метод, бо інакше отримаєш 404 або method not allowed. Друга — named route, щоб у шаблонах не було “жорстких” посилань. Третя — middleware, щоб доступи не були випадковістю. Це і є мінімальний стандарт для реального проєкту.
Далі йдуть контролери — app/Http/Controllers. Їх роль — координувати, а не “робити все”. Тонкий контролер приймає Request, викликає сервіс, і повертає Response. Якщо ти бачиш у контролері 300 рядків з умовами, SQL-запитами, обробкою файлів і форматуванням — це вже червоний прапор. Такий код складно тестувати, і він завжди ламається при розширенні.
Laravel дає кілька типових форм контролерів. Resource controller — стандартний CRUD-набір для сутностей, і він хороший для адмінок. Single action controller — коли потрібно зробити одну дію і тримати її ізольовано. Мінімальний стандарт: CRUD — через resource, спеціальні дії — окремими action-контролерами або чіткими методами, але без “звалища” логіки.
Request-валидація — окремий шматок структури, який новачки найчастіше ігнорують. В Laravel правильний шлях — FormRequest у app/Http/Requests. Туди виносяться правила валідації і, за потреби, авторизація запиту. Чому це стандарт: ти не дублюєш правила по контролерах, не розмазуєш їх по сервісах, і завжди знаєш, де шукати, якщо поле раптом “не проходить”.
Моделі живуть у app/Models. Це не просто “клас для таблиці”, це місце, де описується робота з даними: зв’язки, casts, accessors/mutators, scopes. Мінімальний стандарт: модель не повинна містити важку бізнес-логіку, але вона повинна описувати дані і зв’язки. Якщо ти тягнеш у модель оплату, права доступу і складні сценарії — це вже не модель, а монстр.
Дані і схема бази — це database/migrations і, якщо потрібно, database/seeders. Міграції — єдине джерело правди про структуру таблиць. Мінімальний стандарт тут такий: кожна зміна схеми робиться міграцією, foreign keys та індекси ставляться там, де їх реально потребують фільтри і зв’язки. “Клікати в phpMyAdmin” — це шлях до розсинхрону і болю.
Шаблони лежать у resources/views. У Laravel правильна структура — layouts, сторінки і partials/components. Мінімальний стандарт: ти маєш один або кілька базових layout, а все повторюване виносиш у компоненти чи partials. У Blade не має бути SQL і складної бізнес-логіки. Blade — для відображення, не для прийняття рішень.
Статичні ресурси та фронтенд — це resources/js, resources/css і збірка через Vite. Мінімальний стандарт: ти не підключаєш вручну десятки файлів у шаблоні, ти збираєш їх через Vite, і тримаєш структуру фронтенду так само чистою, як бекенд. Це особливо важливо, якщо ви використовуєте Tailwind або будь-який сучасний пайплайн.
Конфігурація живе у config, а змінні середовища — у .env. Мінімальний стандарт: .env не комітиться, конфіги не “хардкодяться” по контролерах, а беруться через config() і env() тільки там, де це потрібно. Коли новачок починає ліпити ключі і параметри прямо в код — він створює техборг і ризики безпеки.
Middleware лежать у app/Http/Middleware. Вони відповідають за “правила на вході”: авторизація, permissions, антибот, локаль, CSRF, throttling. Мінімальний стандарт: доступи і глобальні правила вирішуються middleware, а не умовами “if” в кожному контролері. Це дає єдину точку контролю і менше шансів забути перевірку.
Авторизація на рівні домену робиться через Policies і Gates. Політики зазвичай лежать у app/Policies і описують, хто може бачити/редагувати/видаляти конкретний ресурс. Мінімальний стандарт: якщо в проєкті є ролі й права — вони мають перевірятися однаково: через middleware для входу в розділ і через policy для дій з конкретним записом. Інакше буде хаос і діри в доступах.
Сервісний шар — це те, що в реальних проєктах рятує структуру. Laravel не нав’язує тобі app/Services, але в командній роботі це мінімальний стандарт для бізнес-логіки: create/update, транзакції, інтеграції, робота з файлами. Контролер викликає сервіс, сервіс виконує сценарій, модель зберігає дані, а Blade показує результат. Це проста схема, але вона масштабується.
Логи й дебаг — storage/logs і системи типу Telescope (якщо вмикати). Мінімальний стандарт: будь-який 500 дивишся в лог, а не “тикаєш” у код. Логи — це спосіб відстежити реальні помилки, особливо коли проблема не відтворюється на першому кліку. Це дисципліна, яку треба закладати новачку одразу.
Як підсумок: мінімальний стандарт Laravel-структури — це правило “кожна річ на своєму місці”. Routes відповідають за мапу URL, middleware — за правила входу, контролери — за координацію, FormRequest — за валідацію, сервіси — за бізнес-логіку, моделі — за дані та зв’язки, Blade — за UI, міграції — за схему бази, конфіги — за параметри середовища. Якщо ти тримаєш цю структуру, проєкт росте спокійно і прогнозовано.
Висновок: структура Laravel — це не “красива теорія”, а спосіб не зламати продукт, коли задач стане багато. Новачку потрібно з першого дня привчитися не змішувати рівні: не тягнути логіку в Blade, не писати SQL в контролері без потреби, не хардкодити конфіги й не обходити middleware. Тоді кожен наступний модуль буде будуватися однаково, і команда зможе рухатися швидко без постійних пожеж.
