Общая концепция

Этот документ даёт концептуальную сводку целевого решения. Он отвечает на вопрос “какую систему строим”, а не “что уже реализовано в текущем репозитории”.

Текущее состояние репозитория и локального окружения описаны в ../index.md и ../40-operations/deployment.md. Если нужен планируемый backend layout, см. ../20-architecture/module-layout.md.

Три слоя данных

CANONICAL PRODUCT   — наша единая единица товара
        ↑ matching
SUPPLIER OFFER      — нормализованное предложение поставщика
        ↑ parsing
RAW PAYLOAD         — сырые данные от поставщика (immutable)

Жёсткое разделение этих слоёв — ключевое архитектурное решение. Смешение — главная ловушка для подобных систем. См. ../10-business/domain-model.md.

Модель идентичности

Товар идентифицируется через Identity Profile — шаблон, описывающий, какие характеристики критичны для данной группы товаров. Профиль применяется предикатом к характеристикам. Идентичность не привязана к категории.

См. ../10-business/product-identity.md.

Архитектурный стиль

Целевое состояние: монолитное приложение или несколько крупных сервисов из независимых модулей по clean architecture.

доменные модули: catalog, offers, pricing, search, matching, enrichment, meta-search;
connector-модули: отдельная интеграция на каждого поставщика;
общее инфраструктурное ядро: конфигурация, observability, messaging, storage adapters.

Ядро не знает о конкретных поставщиках. Новый поставщик = новый connector-модуль. Конкретная файловая раскладка и границы модулей описаны в ../20-architecture/module-layout.md.

См. ../20-architecture/module-layout.md.

Коммуникация

Kafka как шина событий. Event Sourcing для canonical product и ключевых dictionary (manufacturer, characteristics). Для истории цен/остатков — append-only в ClickHouse.

См. ../20-architecture/event-sourcing.md.

Хранение данных

Хранилище	Роль
PostgreSQL	source of truth, OLTP, event store
Elasticsearch	полнотекстовый и faceted поиск, fuzzy, vectors
ClickHouse	история, аналитика
Redis	кэш, rate limiter, locks
Kafka	event bus, event sourcing distribution
S3 / MinIO	raw payloads, media

MongoDB не используется.

Типовые потоки

Обновление каталога: Connector → raw storage → normalize → matching → canonical update → projections (ES/CH).
Мета-поиск: estimate → parse dirty lines → search candidates → pricing → optimize → explain.

Подробнее — в ../20-architecture/high-level-architecture.md.

AI-стратегия

AI применяется там, где даёт ясную ценность и поддаётся кэшированию: парсинг грязных позиций сметы, нормализация алиасов, матчинг probable-случаев, enrichment характеристик. Всегда — confidence score, явный source и human-in-the-loop.

См. ../10-business/contexts/search.md и ../20-architecture/principles.md.

Tracium

Разделы