Архитектура Laravel-проекта — это то, как разложен код: где живёт бизнес-логика, где работа с базой, где обработка запроса. Стандартный MVC подходит для простых проектов, но по мере роста системы «толстые» контроллеры превращаются в проблему: их тяжело тестировать и переиспользовать. Решение — вынести логику в отдельные слои.
Ниже — как мы структурируем индивидуальную веб-систему на Laravel, чтобы её было легко развивать и передавать другим разработчикам.
Почему одного MVC мало
В классическом MVC контроллер принимает запрос и сразу делает всё: валидирует, обращается к базе, считает, отправляет уведомления. Пока логики немного — это удобно. Когда бизнес-правил становится десятки, контроллер разрастается до сотен строк, дублируется между методами и не поддаётся юнит-тестированию без поднятия всего приложения. Это и есть «толстый контроллер» — главный симптом того, что архитектуру пора расслоить.
Сервисный слой: одна задача — один класс
Сервис — это PHP-класс с единственной ответственностью: OrderService, PaymentService, NotificationService. Контроллер становится тонким: принял запрос, проверил доступ, вызвал сервис, вернул ответ. Вся бизнес-логика — внутри сервиса.
- Переиспользование — один и тот же сервис вызывается из контроллера, из консольной команды и из очереди.
- Тестируемость — сервис тестируется юнит-тестом изолированно, без HTTP и без всей базы.
- Читаемость — по имени класса сразу понятно, где искать нужную логику.
Репозитории: изоляция работы с данными
Репозиторий скрывает детали доступа к данным (Eloquent) за понятным интерфейсом: OrderRepository::findActiveByClient() вместо цепочек запросов прямо в сервисе. Это делает модели чище, а замену источника данных или оптимизацию запросов — локальной: меняется один слой, а не вся система. Репозитории оправданы не всегда — для простого CRUD они избыточны; их вводят там, где логика выборки нетривиальна и повторяется.
Как это выглядит вместе
| Слой | Ответственность | Пример |
|---|---|---|
| Controller | приём запроса, проверка доступа, ответ | OrderController |
| Form Request | валидация входных данных | StoreOrderRequest |
| Service / Action | бизнес-логика | CreateOrderService |
| Repository | доступ к данным | OrderRepository |
| Model | сущность и связи | Order |
Дополнительно мы используем Form Requests для валидации, Resources для форматирования ответов API и события/слушатели для побочных эффектов (отправка письма после заказа). Это стандартные инструменты Laravel — мы не изобретаем свой фреймворк, а применяем встроенные механизмы по назначению.
Что это даёт бизнесу
Архитектура — это не «красота ради красоты», а деньги и сроки на дистанции:
- Новый разработчик находит нужный код за минуты и быстрее входит в проект.
- Изменения не ломают всю систему — затрагивается один слой.
- Юнит-тесты покрывают бизнес-логику и ловят ошибки до релиза.
- Систему проще развивать: добавить функцию — значит добавить сервис, а не переписать контроллер.
На эту архитектуру дальше «ложатся» API для мобильных приложений (см. про проектирование REST API), система прав (см. про роли и доступ) и автоматический деплой (см. про CI/CD). Нужна надёжная веб-система с продуманной архитектурой — вот разработка индивидуальной веб-системы.