В прошлом посте обещал подробнее рассказать про архитектуру админки AutoBagaz. Проект развивается на Laravel, и одна из основных задач здесь — организовать данные, на которых работает подбор оборудования. Карточку товара заполнить относительно просто. Сложнее описать, на какие автомобили он устанавливается, при каких условиях подходит и где есть исключения. 1. Каталог и применяемость — разные части системы В каталоге хранятся сами товары: производитель, цена, остаток и характеристики. Отдельно описываются автомобили: модели, поколения, кузова и типы крыши. Для багажных систем это существенно: одинаковое название модели ещё не означает одинаковый способ установки. Дальше эти данные нужно связать. Именно здесь появляется применяемость — информация о том, для каких вариантов автомобиля подходит оборудование. Если смешать всё в описании товара, текст прочитает покупатель, но использовать его для надёжного подбора будет сложно. 2. Группы применяемости вместо списка в каждой карточке В админке предусмотрены группы применяемости, к которым привязываются товары. Так связь с автомобилями становится самостоятельной частью данных. Её можно проверять и сопровождать отдельно от цены, фотографий и описания товара. Для работы с такими группами есть копирование и статус проверки. Копирование помогает подготовить похожую привязку, а статус позволяет учитывать, проверены ли внесённые сведения. При этом похожая запись сама по себе ещё не доказывает совместимость: отличия по кузову или крыше могут оказаться решающими. 3. Универсальность тоже нужно описывать явно У товаров есть разные режимы применяемости: "vehicle_fitment" и "universal". Первый предполагает подбор с учётом автомобиля. Второй позволяет отдельно учитывать универсальные товары. Но слово «универсальный» не снимает технические ограничения. Например, при установке оборудования могут иметь значение расстояние между поперечинами и максимальная нагрузка. Поэтому наличие товара в подходящей категории и подтверждённая возможность установки — разные вещи. 4. Исключения и проверка результата В админке есть ручные исключения и предпросмотр совместимости. Исключения нужны для ситуаций, которые нельзя корректно описать общим правилом. Предпросмотр помогает увидеть результат подбора и проверить, соответствует ли он ожидаемому сценарию. Это важная часть работы: недостаточно сохранить связи — нужно понимать, что на их основе получит покупатель. Для меня архитектура такой админки складывается из трёх частей: данные о товарах и автомобилях, связи между ними и инструменты проверки этих связей. Чем точнее разделены эти задачи, тем понятнее, где искать ошибку: в характеристиках товара, описании автомобиля или применяемости. А вам приходилось делать админку, где основной сложностью были правила и связи между сущностями? Как организовали их проверку?