<b>Laravel-проект, который не разваливается: 7 вещей, которые фиксируют порядок</b>

<b>Laravel-проект, который не разваливается: 7 вещей, которые фиксируют порядок</b>

Если проект живёт дольше пары спринтов, хаос почти всегда приходит через одно и то же: разъезжающиеся слои, жирные контроллеры, магию в моделях и «временные» костыли, которые потом никто не находит.

— Контроллер отвечает только за вход/выход. Вся бизнес-логика уезжает в сервисы, action-классы или доменные объекты.
— Валидация не размазана по коду: Form Request для HTTP, отдельные правила для внутренних сценариев.
— Модели не становятся свалкой. Accessor, mutator, observer и scope — только если это реально про поведение модели.
— Запросы к БД не прячутся в шаблонах и не живут в циклах. Всё тяжёлое — в репозитории, query object или отдельном классе.
— Имена файлов и классов должны объяснять роль без чтения содержимого. Если название надо расшифровывать — уже проблема.
— Любой «быстрый фикс» либо сразу оборачивается тестом, либо помечается как временный технический долг. Иначе он становится постоянным.
— Общие правила для проекта лучше держать в одном месте: формат ответа, обработка ошибок, авторизация, типовые DTO.

Laravel сам по себе не спасает от архитектурной каши. Он просто позволяет написать её быстрее, если не держать границы.

Хорошая привычка: перед новым фичерным кодом спросить себя, куда пойдёт логика через 3 месяца. Если ответ «везде» — это сигнал остановиться.