Масштабирование каталога под разные разделы

Задача по масштабированию каталогов

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

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

Что меняется вместе с типом каталога

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

Что можно переиспользовать, а что нет

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

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

Как это выглядит в коде и структуре

У каталогов остаются отдельные функции запросов и типы карточек. Общие механизмы обрабатывают загрузку, ошибки и пагинацию. Состояние маршрута, поиск и фильтры учитывают параметры конкретного раздела.

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

На что приходится идти ради устойчивости

Цена такого подхода - чуть больше явного кода. У каждого каталога остаются собственные модели и точки настройки. Зато изменения в рецептах не ломают рейтинги организаций, а правила товаров не просачиваются в каталог жилых комплексов.

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

Что это даёт при развитии проекта

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