Laravel-проект часто ломается не в коде, а в скрытых допущениях команды

Laravel-проект часто ломается не в коде, а в скрытых допущениях команды

В Laravel слишком легко начать с удобства: фасады, магические биндинги, быстрые контроллеры. Но через пару месяцев проект упирается в места, где никто не договорился о границах: где живёт бизнес-логика, кто отвечает за транзакции, как обрабатываются ошибки и события.

Есть 4 правила, которые спасают от хаоса:
— контроллер только принимает и отдаёт, без тяжёлой логики;
— сервисы не знают про HTTP;
— транзакция живёт на одном уровне, а не размазана по вызовам;
— любые side effects выносятся в события, jobs или listeners.

Отдельно проверь, не прячется ли критичный код в Observer, mutator или callback внутри коллекции. Такие места удобно писать, но неудобно тестировать и сопровождать. Ещё один частый провал — смешать авторизацию, валидацию и доменную проверку в одном методе: потом невозможно понять, почему запрос запрещён или просто не проходит правило.

Если проект уже разросся, начни не с рефакторинга всего подряд, а с одного маршрута: распиши поток данных от request до response и отметь, где именно появляются зависимости, сайд-эффекты и исключения. Обычно после такого карта проблем становится очевидной.