ADR-0012: Движок Data Visibility Policy
Status: accepted Date: 2026-04-17 Deciders: команда проекта
Контекст
Не вся информация в нашей системе должна быть доступна каждому клиенту:
- Запреты по поставщикам / производителям (конфликты интересов, NDA, эксклюзивы).
- Ограничения по ценовым диапазонам.
- Скрытие некоторых атрибутов (точная цена → диапазон, конкретный бренд → “по запросу”).
- Скрытие конкретных складов или логистических условий.
- B2C vs B2B разграничения.
- Ролевые ограничения внутри организации клиента (закупщик vs руководитель).
Альтернативы:
- A: Hardcoded rules в коде сервисов.
- B: Per-customer scope flags (упрощённая модель).
- C: Полноценный policy engine с DSL над любыми атрибутами.
Решение
Полноценный Data Visibility Policy engine как самостоятельная подсистема.
- Сущность
DataVisibilityPolicy: subject, target_kind, effect (allow/deny/transform), predicate (DSL), priority. - Predicate DSL поддерживает логические + сравнительные + специальные (matches_tag, characteristic_eq, etc.) операции.
- Transform-эффекты позволяют скрывать поля, обобщать значения, заменять.
- Policy compilation в исполнимое представление + кэш.
- Точки enforcement: search, pricing, estimate, API response shaping, analytics, webhooks.
- Управление через admin UI с симулятором “что увидит клиент X”.
- Audit-trail (event-sourced).
Последствия
Плюсы
- Гибкость: новое требование к видимости — это новая policy, не код.
- Единая точка контроля доступа к данным.
- Объяснимость: можно показать клиенту/админу, какие правила применились.
- Симулятор и audit поддерживают governance.
Минусы
- Дополнительный сервис.
- Performance budget — на горячем пути запросов.
- DSL нужно поддерживать и расширять.
- Риск over-engineering: можно нагенерить много policies, которые конфликтуют — нужна дисциплина.
Нейтральные последствия
- Альтернатива RLS в PostgreSQL — но нам нужна гибкость по target_kind (не только rows БД, но и API responses, агрегаты).
Рассмотренные альтернативы
A: Hardcoded в коде
Не масштабируется. Каждое новое требование — изменение кода. Сложно объяснить и аудировать.
B: Per-customer scope flags
Слишком упрощённо: невозможны ограничения по ценам, характеристикам, transform-эффекты.
PostgreSQL RLS
Хороший инструмент для row-level security в БД, но недостаточен для:
- Применения к ES-проекциям.
- Transform-эффектов.
- Применения в API response shaping.