Как сделать на laravel сайт, CRM или интернет‑магазин с нуля

Эта статья представляет собой рабочий чек‑лист: как сделать на Laravel веб‑проект уровня коммерческого продукта, а не учебный «todo list». По шагам пройдём путь от идеи и структуры database до деплоя и поддержки. Текст полезен джунам и мидлам, тимлидам, а также фаундерам, которым нужно понимать, что именно требовать от команды и по каким признакам оценивать качество реализации.

Когда действительно стоит делать на Laravel: типы задач, ограничения, альтернативы

Laravel логично брать там, где важна скорость разработки, чистый php‑код и продуманная экосистема. Фреймворк хорошо работает как основа веб приложений с богатыми функциями управления контентом и пользователями, где маршрутизация, модели, представления и api образуют единое целое.

• — B2C/B2B веб‑сервисы, где каждому пользователю нужен личный кабинет: биллинги, обучающие платформы, SaaS‑сервисы. Здесь Laravel удобно use как backend: модели, controllers, policies, очереди, уведомления.
• — CRM‑системы, helpdesk, внутренние панели для отдела продаж или поддержки. Удобно быстро создавать новые сущности, миграции, отчёты, делать сложного ничего не нужно — всё есть в коробке.
• — Интернет‑магазины с нетиповыми правилами ценообразования, интеграциями и нестандартным каталогом, где классический CMS уже мешает. Laravel даёт гибкий route‑слой, blade‑шаблоны и понятную структуру resource‑контроллеров.
• — Бэкенд для мобильных приложений и игр: REST/JSON:API, авторизация, ин‑апп‑покупки, админка, api‑методы для аналитики.

Не лучший выбор:

• — Сверхвысоконагруженные real‑time‑системы с миллионами одновременных соединений (игровые сервера, стриминг, чаты ядра). Там выгоднее Go, Elixir, иногда Node.js. Laravel можно использовать как вспомогательный сервис, но не как основной realtime‑движок.
• — Проекты, где уже есть устоявшийся стек и большой объём legacy‑кода. Переписать monolith на Laravel ради моды почти всегда дороже, чем развивать текущую систему.

Как понять, что команда умеет делать на Laravel «по‑взрослому»? Задайте несколько прямых вопросов:

• — Как выглядит структура проекта: где находятся models, services, actions, views, есть ли разделение по bounded contexts или всё свалено в app/Http/Controllers?
• — Как они делают миграции и изменения таблицы: есть ли zero‑downtime‑подход, rollback‑стратегия, план migrate для продакшена?
• — Какие есть тесты, какой уровень покрытия, используется ли phpstan/psalm, как организован CI/CD?
• — Как они обновляют версии фреймворка и зависимостей, что делают при переходе на новую major‑версию?

Если команда кладёт большую часть бизнес‑логики прямо в контроллер, не умеет ответить, как устроен pipeline деплоя и откат изменений, — перед вами подход уровня учебного проекта.

Подготовка и архитектура: что продумать до первой команды artisan

Сильный Laravel‑проект начинается не с php artisan new, а с понимания, какие сущности и процессы будет отражать система. Даже для простой CRM полезно описать базовую структуру.

• — Список сущностей: пользователь, роль, компания, сделка, контакт, счёт, файл.
• — Действия: создать, изменить, привязать к компании, сменить статус, получить отчёт.
• — Сценарии входа и выхода пользователя: регистрация, восстановление, смена прав, блокировка.

Минимальный набор артефактов: краткое ТЗ, text‑список пользовательских сценариев и диаграмма сущностей/связей. Это позволяет сразу спроектировать базы и избежать хаоса из десятков несвязанных миграций.

Следующий шаг — выбор архитектурного подхода. Базовый MVC в Laravel — это отправная точка, но для коммерческого продукта полезно добавить уровни:

• — Модульная структура: вместо одного app/Http/Controllers создать папки по доменам (например, App/Domain/Users, Deals, Billing), где рядом находятся models, actions, политики.
• — Сервисы и Actions: каждый бизнес‑method, например CreateDealAction, представляет собой отдельный класс. Контроллер только принимает http‑запрос, вызывает action и возвращает ответ пользователю или api.
• — Репозитории — по ситуации. Если проект не требует различных источников данных (database + внешние сервисы), можно не усложнять.

Технологические решения стоит зафиксировать заранее:

• — Database: для большинства проектов подойдут MySQL или PostgreSQL. PostgreSQL выигрывает там, где много сложных запросов, jsonb‑поля, полнотекстовый поиск.
• — Аутентификация: Laravel Breeze быстро даёт готовый вход, регистрацию, reset пароля с blade‑шаблонами. Jetstream — более тяжёлый, но с командами, профилями, 2FA.
• — API: если фронтенд — SPA или мобильные клиенты, логично сделать чёткий REST api или JSON:API. GraphQL нужен не всем и усложняет схему, зато даёт гибкость выборки данных.
• — Фронтенд: простые панели — Blade + Alpine.js и Tailwind. Сложные интерфейсы — Vue/React через Inertia или полноценный SPA с отдельным репозиторием.

Среда разработки: используйте Docker или Laravel Sail, чтобы у всех разработчиков и на сервере была одна и та же структура сервисов. Настройки выносите в .env: отдельные файлы для dev, stage, prod. В Git — основной main/master, ветки feature/*, обязательный code review и запрет пушить прямо в прод.

Пошаговое руководство: как сделать на Laravel рабочий вебпроект

Шаг 1. Создание и базовая настройка проекта.

• — Установка через composer: команда composer create-project laravel/laravel app или laravel new app, если глобально установлен инсталлер. Сразу подключите репозиторий: git init, git remote add origin …
• — В config/app.php задайте локаль, временную зону, имя приложения. В config/database.php — подключение к нужной СУБД. Проверьте, что настройки кэша и очередей соответствуют планируемой нагрузке.
• — Подключите логирование ошибок в Sentry/BugSnag или отправку отчётов в Slack. Это часто забывают на старте, и потом сложно отлавливать первые баги.

Шаг 2. Моделирование данных и миграции.

• — Для каждой сущности создайте миграцию и модель: php artisan make:model Deal -m. Продумайте ключи, связи, индексы. Любой запрос, который чаще 1 раза в минуту получает данные по полю, должен иметь индекс.
• — Используйте сиды: php artisan make:seeder RolesTableSeeder, чтобы заполнять справочники, тестовых пользователей и demo‑данные. Это сильно ускоряет разработку и тестирование.
• — Не жёстко завязывайтесь на текущие требования. Например, вместо отдельной таблицы для статусов можно использовать config или справочник, к которому легко добавить новые значения.

Шаг 3. Маршруты, контроллеры и слои приложения.

• — Разделите маршруты: routes/web.php для html‑страниц, routes/api.php для json‑ответов. Для каждой главной сущности создайте resource‑маршруты: Route::resource(‘deals’, DealController::class).
• — Не кладите бизнес‑логику в контроллер. Пусть контроллер только получает запрос, авторизует пользователя, передаёт данные в сервис и возвращает представления или json‑ответ.

Шаг 4. Валидация, формы и пользовательский опыт.

• — Используйте FormRequest: php artisan make:request StoreDealRequest. В rules() описывайте логику, в messages() — понятные сообщения. Так логику валидации легко переиспользовать в различных частях проекта и api.
• — Для blade‑форм делайте единый шаблон ошибок, чтобы под каждым полем показывались локализованные тексты, а не «The field is required» по умолчанию.

Шаг 5. Аутентификация, роли и права доступа.

• — Стандартный вход и регистрации можно получить через Breeze (php artisan breeze:install). Дальше подключайте Policies: php artisan make:policy DealPolicy для сущности сделок.
• — В Policy описывайте, кто может видеть, создавать, обновлять, удалять ресурс. В контроллере вызывайте this->authorize(‘update’, $deal). Не пишите проверки вида if ($user->role === ‘admin’) прямо в методах.

Шаг 6. Работа с файлами, очередями и уведомлениями.

• — Для файлов используйте Storage: локальное хранилище для dev, S3/совместимое для прод. Настройки — в config/filesystems.php и .env.
• — Тяжёлые операции (отправка писем, генерация отчётов, синхронизация с внешними системами) выносите в очереди: Jobs + Queue workers. Это критично для стабильности под нагрузкой.
• — Notifications позволяют из одного места отправлять различные типы событий: email, Slack, Telegram. Опишите их, а затем вызывайте notify() у модели пользователя.

Шаг 7. Тестирование и качество.

• — Покройте тестами ключевые user‑флоу: регистрация, создание сущности, изменение прав, критические отчёты. Feature‑тесты проверяют маршруты и http‑ответы, Unit‑тесты — бизнес‑логику сервисов.
• — Используйте phpstan или psalm, чтобы поймать ошибки типов и неочевидные баги ещё до запуска тестов.

Шаг 8. Деплой и минимальный CI/CD.

• — Настройте GitHub Actions/GitLab CI: on push в main запускать composer install, php artisan test, phpstan. При успехе — деплой на сервер.
• — Для продакшена используйте команды php artisan config:cache, route:cache, а миграции запускайте с учётом возможных блокировок таблиц. При необходимости — сначала добавить столбец, потом код, потом удалить старый.

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

Когда первый релиз готово и проект выходит к реальным пользователям, основная задача — не дать ему развалиться под нагрузкой и изменениям требований.

• — Оптимизация: кэшируйте тяжёлые запросы в Redis, используйте cache tags, храните сессии и очереди вне файловой системы. Профилируйте N+1‑запросы (laravel debugbar, telescope) и добавляйте недостающие индексы.
• — Безопасность: Laravel уже даёт защиту от SQL‑инъекций через Query Builder и Eloquent, CSRF‑токены в формах и escape html в blade. Дополнительно настройте Content Security Policy, правильные заголовки, шифрование cookies и ограничение доступа к админке по адресу/ролям.
• — Поддержка: ведите backlog технического долга, фиксируйте, какие части нужно переписать при росте нагрузки. Планируйте обновление версии фреймворка хотя бы раз в год, чтобы не застрять на устаревшей ветке, где уже нет security‑обновлений.

Итоги и как мы можем помочь

Сделать на Laravel современный веб‑проект реально, если совместить продуманную архитектуру, аккуратную работу с models, controllers, views и дисциплину разработки: миграции, тесты, деплой, мониторинг. Такой подход позволяет проекту не только стартовать, но и эволюционировать без переписывания с нуля.

Если у вас нет собственной сильной команды, мы можем взять на себя полное создание проекта: от проектирования структуры app и базы до разработки веб‑сервиса, CRM, интернет‑магазина или backend‑api для мобильного приложения и игры. Помогаем с архитектурой, реализацией, настройкой сервера и дальнейшим сопровождением — чтобы вы получили не учебный pet‑проект, а надёжную систему для бизнеса.