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

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

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

Получается цепочка: Автомобиль → Базовый багажник → Автобокс

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

⚙️ Что происходит на уровне данных Первый вариант — хранить у каждого товара список совместимых автомобилей.

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

В проекте для этого используются группы применяемости — Fitment. К одной группе можно привязать несколько конфигураций автомобилей и несколько товаров.

Связи many-to-many позволяют управлять такими наборами без ручного перечисления каждой пары «автомобиль — товар». В Laravel эти отношения удобно описывать через Eloquent ORM. Но сама ORM не решает главную задачу — определить сущности предметной области и смысл связей между ними.

🔗 Совместимость — это несколько задач

Подобрать багажник под автомобиль и подтвердить возможность установки автобокса на этот багажник — разные проверки.

Сейчас основной подбор в AutoBagaz построен вокруг применяемости багажников к конфигурациям автомобилей. В коде также предусмотрена техническая проверка пары «багажник — автобокс»: по размерам профиля дуг, параметрам креплений и расстоянию между поперечинами. Но сейчас для автобоксов используется универсальная стратегия, поэтому техническая проверка не участвует в подборе.

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

🛠 Административная панель тоже влияет на решение

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

Удобство наполнения каталога напрямую влияет на качество подбора.

Почему Laravel?

Laravel позволяет развивать собственную предметную логику внутри приложения и описывать нужные проекту связи.

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

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

💡 Что в итоге

Сложность интернет-магазина далеко не всегда определяется количеством товаров или страниц.

Иногда самая интересная часть скрывается за обычной кнопкой «Подобрать по автомобилю». Именно там встречаются предметная модель, качество данных и пользовательский опыт.

В следующих публикациях хочу подробнее разобрать административную часть и организацию групп применяемости.

А вам приходилось реализовывать каталоги со сложными правилами совместимости? Как организовывали данные и где разме