ADR-0007: Category-agnostic модель через Identity Profiles

Status: accepted Date: 2026-04-17 Deciders: команда проекта

Контекст

Привязка критических характеристик к категории товара создаёт риск:

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

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

Решение

Ввести сущность Identity Profile:

• Profile содержит matcher (предикат по характеристикам) и critical_attribute_keys.
• object_type и связанные классификационные характеристики — обычные Characteristic с особой ролью object_type.
• Иерархии категорий в доменной модели нет.
• Поставщиковые classification trees (например, gdsClassTree у ETM) сохраняются как classification_tag (для UX-фильтров и поиска), но не участвуют в доменной логике.

Последствия

Плюсы

• Модель одинаково работает для разных доменов (электрооборудование, метизы, гидравлика).
• Добавление нового поставщика не требует унификации его классификатора с нашим.
• Identity Profile эволюционирует независимо (ML/человек создаёт новые профили по мере роста каталога).
• Возможность одному товару подпадать под несколько профилей (разрешение по приоритету).

Минусы

• Сложнее для неподготовленного разработчика: “нет категорий” удивляет.
• Требуется governance-процесс для управления профилями.
• Семантика matcher’ов должна быть строго определена (DSL).

Нейтральные последствия

• Если у поставщика есть собственный классификатор, его можно использовать как источник тегов и кандидатов на matcher’ы, но не как часть доменной идентичности.

Рассмотренные альтернативы

Оставить категории как first-class

Проблемы описаны выше.

Tagging без структуры

Слишком слабая модель для надёжного матчинга.

Ссылки

• ../../10-business/product-identity.md