Матчинг
NOTE
Статус: Target service boundary. Документ описывает целевую сервисную границу. Код либо полностью отсутствует, либо существует только как scaffold — смотрите секцию «Статус документа» ниже для точного указания на код. Правила маркировки — в
50-processes/documentation-standard.md.
Этот README описывает целевую сервисную границу matching. Читайте его, когда нужно понять, как supplier offer привязывается к canonical product и где проходят границы между deterministic, heuristic и human-in-the-loop решениями.
Назначение
Привязка supplier offer к canonical product с уровнем уверенности и маршрутизацией слабых кейсов в модерацию или enrichment.
Статус документа
- Тип знания:
target service boundary - Статус реализации: отдельный runtime и код сервиса пока отсутствуют
- Текущее место кода: реализация matching в
backend/ещё не выделена; текущий код ограничен минимальным API-scaffold - Что читать дальше:
../../10-business/contexts/matching.md,../catalog-core/README.md,../enrichment/README.md
Область действия
Входит:
- Детерминированный матчинг по идентификаторам и критичным признакам.
- Эвристический матчинг по характеристикам и поисковым кандидатам.
- LLM-верификация вероятных кандидатов через enrichment.
- Генерация решений
matching.decided.
Не входит:
- Хранение canonical product как агрегата.
- Ручная модерация как UI/операторский процесс.
Публичный контракт
Вход
- Потребляет
offer.normalized.v1. - Читает кандидатов из search/catalog-related read models.
Выход
- Публикует
matching.decided.v1. - Для слабых кейсов публикует
moderation.requested.v1.
Внутренняя архитектура
В целевом состоянии matching сочетает deterministic rules, candidate generation, scoring и handoff в enrichment/moderation. Он должен быть изолирован от хранения canonical aggregates и работать через чёткие доменные порты.
Зависимости
- Search и catalog-related read models.
- Kafka для входных и выходных событий.
- PostgreSQL/кэш для состояния пайплайна при необходимости.
Хранилище
- В текущей документации точный storage-contract не зафиксирован.
- При появлении реализации он должен быть описан в
20-architecture/schemas/.
Конфигурация
| Env var | Default | Описание |
|---|---|---|
MATCHING_CONFIDENCE_THRESHOLD | — | порог auto-match |
MATCHING_LOG_LEVEL | info | уровень логирования |
Локальный запуск
Выделенного процесса matching в текущем репозитории нет.
Тестирование
- Unit-тесты rules/scoring обязательны.
- Integration-тесты нужны на поток
normalized offer -> decision. - Слабые кейсы должны покрываться fixture-based regression наборами.
Наблюдаемость
В целевом состоянии нужны метрики auto-match rate, moderation rate, latency candidate generation и distribution confidence. Сейчас отдельной observability-поверхности нет.
Открытые вопросы / TODO
- Формализовать DSL matcher для identity profile.
- Спроектировать rematcher worker по изменениям dictionary и profile.