Laravel.
Сложная логика.
Удобный продукт.

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

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

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

Контроллер принимает запрос, но не должен содержать весь бизнес-процесс. Form Request проверяет форму данных: количество — целое число в допустимом диапазоне, адрес относится к выбранному клиенту. Затем политика доступа проверяет полномочия сотрудника, а прикладной сервис выполняет действие. Синтаксически корректный запрос ещё не означает, что скидка разрешена.

Цена, скидка и итог пересчитываются сервером. Клиент передаёт идентификатор товара и количество, а не сумму, которой приложение обязано доверять. Ошибки возвращаются рядом с полями; интерфейс сохраняет введённые данные и объясняет следующий шаг.

Проверяем на проекте
Приёмка: повторить запрос напрямую к API, подменить цену, отправить дробное и отрицательное количество. Сервер должен отклонить нарушение независимо от интерфейса.

У заказа есть позиции, клиент, версия условий и история изменений. Денежные значения храним с явной валютой и точностью: например, целым числом минимальных денежных единиц. Позиция хранит снимок цены на момент оформления, иначе изменение прайс-листа перепишет историю продажи.

Создание заказа и его позиций выполняем в транзакции базы данных. Для конкурирующего резервирования выбираем подходящую блокировку или проверку версии. Внешний HTTP-запрос к ERP не делает локальную транзакцию распределённой: для обмена предусматриваем отдельное состояние и повторную доставку.

Проверяем на проекте
Приёмка: два сотрудника одновременно заказывают последний доступный остаток. Проверяем согласованное поведение, а не только успешный одиночный запрос.

Для собственного браузерного кабинета можно использовать сессионную аутентификацию; для сторонних клиентов — подходящую токеновую схему. Sanctum поддерживает оба сценария, но выбор и настройка зависят от доменов и клиентов. Пароли, сессии, восстановление доступа и защита от перебора требуют отдельной конфигурации.

Одной роли «менеджер» недостаточно. Политика должна учитывать компанию пользователя, принадлежность заказа, этап процесса и лимит согласования. Пользователь одной дилерской организации не должен читать данные другой, даже если угадает идентификатор. Проверки распространяются на выгрузки, вложения и фоновые действия.

Проверяем на проекте
Составляем матрицу «роль × действие × область данных» и проверяем запреты автоматическими тестами. Двухфакторный вход и срок жизни сессии выбираем по требованиям проекта.

Описываем ресурсы, обязательные поля, формат ошибок, пагинацию и правила совместимости. Для мобильного приложения и партнёрских систем полезна спецификация OpenAPI с примерами. API Resources помогают контролировать выдаваемые поля; внутренние атрибуты модели не должны попадать в ответ случайно.

Создание заказа может вернуть 202 Accepted, если обмен с ERP ещё впереди. Ответ содержит идентификатор и статус, по которому клиент узнает результат. Удаление или переименование поля требует согласованной миграции клиентов; номер версии URL сам по себе эту задачу не решает.

Проверяем на проекте
Приёмка: контрактные тесты на обязательные поля, ограничения доступа, пустые списки и предсказуемый формат ошибки. Пример ниже — проектный контракт, а не встроенный маршрут Laravel.

ERP может принять заказ, а соединение оборваться до ответа. Поэтому повторная отправка не должна создавать второй документ. Клиентский ключ идемпотентности связываем с компанией и контрольной суммой запроса; повтор с тем же ключом и другими данными отклоняем. На стороне получателя согласуем уникальный внешний идентификатор.

Для важных событий используем журнал отправки: запись заказа и события создаются атомарно, обработчик доставляет событие отдельно. Вебхуки проверяем по подписи и сроку допустимости, сохраняем идентификатор события. Таймаут, число повторов и ручное восстановление входят в проект интеграции.

Проверяем на проекте
Приёмка: повтор события, ответ 500, таймаут после принятия заказа и нарушение порядка уведомлений. Статус «отправлен» не равен статусу «принят ERP».

Импорт каталога, формирование документа и отправка уведомления могут выполняться в очереди. Пользователь получает понятный статус, пока длительная операция работает отдельно. Критичные задания отделяем от массовых рассылок, чтобы большой импорт не задерживал подтверждение заказа.

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

Проверяем на проекте
Приёмка: остановить worker посреди обработки и возобновить его. Заказ должен завершиться один раз, а оператор — увидеть причину зависания.

Коммерческие предложения, договоры и счета хранятся отдельно от публичных изображений каталога. Доступ к документу проверяем по пользователю и компании; для скачивания применяем контролируемый маршрут или ограниченную по времени ссылку. Секретный путь не заменяет проверку прав.

Проверяем размер и допустимый тип файла, формируем серверное имя, определяем политику проверки содержимого и сроки хранения. При генерации PDF фиксируем версию исходных данных и шаблона. Объектное хранилище и резервные копии выбираем вместе с требованиями к доступу и восстановлению.

Проверяем на проекте
Приёмка: чужой документ по прямой ссылке, просроченная ссылка, слишком большой файл и файл с подменённым расширением.

Сначала измеряем пользовательские сценарии: открытие каталога, поиск по артикулу, оформление заказа. Смотрим количество SQL-запросов, время внешних вызовов и размер ответа. Индексы, пагинация и загрузка связанных данных часто важнее добавления серверов.

Кэшируем данные с понятным сроком актуальности. Ключ договорной цены включает компанию и версию условий: общий ключ может раскрыть чужую скидку. Изменение цены или прав должно инвалидировать зависимые записи. На оформлении заказа проверяем актуальные условия повторно.

Проверяем на проекте
Целевые задержки и нагрузочный профиль согласуем до теста. Фреймворк не гарантирует конкретный RPS: результат зависит от приложения, базы, инфраструктуры и внешних сервисов.

Laravel можно сочетать с серверными шаблонами, Livewire или отдельным интерфейсом на React/Vue. Выбор зависит от интерактивности и команды. Для публичного каталога продумываем индексируемые URL, метаданные и отображение контента; закрытый кабинет не должен случайно попасть в поиск.

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

Проверяем на проекте
Приёмка: оформление заказа с клавиатуры, увеличение текста, ошибки формы, пустой каталог, медленная сеть и длинные названия товаров.

Проверяем не только успешный заказ. В набор входят границы скидок, изоляция компаний, конкурирующие изменения, повторные события и недоступность ERP. Доменные правила удобно проверять отдельно, а критические цепочки — интеграционными тестами и сценариями браузера.

Технический лог ошибки и журнал бизнес-действий решают разные задачи. В журнале фиксируем сотрудника, действие, время и изменённые значения; секреты и лишние персональные данные не записываем. Сквозной идентификатор запроса связывает портал, задание очереди и обращение к внешней системе.

Проверяем на проекте
Настраиваем оповещения о сбоях обмена, росте ошибок и задержке очереди. Для каждого сигнала нужен ответственный и описанный порядок восстановления.

Разделяем окружения разработки, проверки и production. Секреты не храним в репозитории, отладочный вывод отключаем на публичном сервере. Выпуск включает сборку интерфейса, проверку конфигурации, миграции и перезапуск долгоживущих worker-процессов.

Изменения базы проектируем совместимыми с предыдущим кодом на время выпуска. Откат приложения не отменяет автоматически изменение данных. Перед опасной миграцией нужен отдельный план восстановления и проверенная копия. Резервирование базы, файлов и конфигурации дополняем практической проверкой восстановления.

Проверяем на проекте
Перед передачей проекта фиксируем схему окружений, команды выпуска, график резервирования, доступы ответственных и регламент обновления зависимостей. Конкретные сроки реакции определяются договором поддержки.