[DRAFT] ER: Диаграмма сущностей

Часть 1 Микросервисная архитектура FoodLifeCycleApp. Cхема СУБД доменов: IAD, MDM, INVENTORY PMA

Published

July 14, 2026

WarningОграничение публичной документации

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

  • Полная спецификация метода: Будет доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).

1 Начало

При проектировании реляционных структур и Entity-Relationship (ER) моделей для микросервисной системы FoodLifeCycleApp, требуется соблюдение паттерна Database-per-Service. Для исключения связанности компонентов и предотвращения образования «распределенного монолита», прямые ограничения внешних ключей (FOREIGN KEY) между базами данных изолированных доменов запрещены.

Связанность сущностей на глобальном уровне обеспечивается двумя механизмами:

  1. Сквозной параметр (trace_id): Поле trace_id VARCHAR(50) добавляется (injection) шлюзом в виде заголовка X-Request-ID. Параметр транслируется через gRPC-интерфейсы и сообщения брокера Kafka во все физические базы данных, позволяя сопоставить логи Grafana Loki с изменениями в СУБД без синхронных JOIN-запросов.
  2. Асинхронная репликация Read-моделей: Микросервисы автономно накапливают данные из смежных контекстов через шину событий брокера.

Для повышения читаемости архитектурных схем командами разработки, таблицы на ER-диаграммах визуально сегментированы и раскрашены в соответствии с кодовыми цветами наших Data Flow конвейеров.

2 Примеры ER-диаграмм

2.1 Общая ER-диаграмма

На уровне концептуального проектирования архитектура FoodLifeCycle изолирует данные каждого контекста. Межсервисные связи лишены ограничений FOREIGN KEY и реализуются асинхронно.

Ниже представлена общая схемв взаимодействия распределенных баз данных:

High_Level_Domain_Model_Rectangular AID 6. aid_db Домен AID / Смарт-логи модерации AUTH 1. auth_db Домен IAD / Управление доступом AID->AUTH Валидация нарушений по user_id FRIDGE 4. fridge_db Домен INVENTORY / Холодильник AID->FRIDGE Логирование медиа-сессий по trace_id NOTIF 2. notification_db Контур IAD / Оповещения AUTH->NOTIF Синхронизация очередей по trace_id MDM 3. mdm_db Домен MDM / База рецептов FRIDGE->MDM Проверка справочников по food_element_id MENU 3.5. menu_db Домен MDM / Управление меню MENU->FRIDGE Активация шаблонов по home_group_id AFF 5. affinity_db Домен AFFINITY / Предпочтения AFF->FRIDGE Обновление скоринга по home_group_id BUPAR 7. bupar_db Домен PMA / Сквозной аудит событий BUPAR->FRIDGE Анализ логов процессов по case_id

2.2 ER-модель. Домен (IAD)

В этом домене декомпозированы структуры баз данных auth_db и notification_db. Они отвечают за доступ, управление сессиями, правами групп (HOME / OFFICE) и логирование пуш-нотификаций.

IAD_Engagement_Physical_Model cluster_auth_db СУБД: auth_db (auth-service) cluster_notification_db СУБД: notification_db (notification-service) USERS users uuid id PK varchar email UK varchar password_hash boolean is_active timestamptz created_at timestamptz updated_at GROUP_MEMBERS group_members varchar user_id PK, FK varchar group_id PK, FK varchar role USERS->GROUP_MEMBERS SESSIONS sessions uuid id PK uuid user_id FK, IDX varchar token_hash UK, IDX varchar device_fingerprint varchar ip_address boolean is_revoked timestamptz expires_at timestamptz created_at timestamptz updated_at USERS->SESSIONS GROUPS groups varchar group_id PK varchar space_type boolean is_verified GROUPS->GROUP_MEMBERS PUSH_LOG push_delivery_log int delivery_id PK varchar user_id varchar template_code varchar trace_id IDX varchar status SESSIONS->PUSH_LOG Асинхронный trace_id ERROR_DIRECTORY error_directory uuid id PK varchar error_code UK varchar internal_status jsonb message_translations jsonb resolution_hint_translations varchar min_app_version IDX boolean is_active IDX timestamptz created_at timestamptz updated_at B2B_TRUSTED_STORES b2b_trusted_stores uuid id PK varchar shop_id UK, IDX varchar store_chain_name varchar token_hash IDX boolean is_active timestamptz created_at timestamptz updated_at NOTIF_TEMPLATES notification_templates varchar template_code PK varchar app_lang PK varchar title text body_text

2.3 ER-модель. Домен Мастер-Данных (MDM)

В этом домене декомпозированы структуры базы данных mdm_db. Они отвечают за управление справочников, для базовых рецептов, рецептов пользователей (групп) базовых меню, меню пользоватлей( групп) и карточек продуктов (хранят иноформацию о пищевой ценности продукта).

MDM_Physical_Model cluster_mdm_db СУБД: mdm_db (recipes-service) cluster_menu_db СУБД: menu_db (menu-service) FOOD_ELEMENTS food_elements uuid id PK varchar name UK, IDX (LOWER) varchar status IDX jsonb chemical_card varchar trace_id timestamptz created_at timestamptz updated_at RECIPE_INGREDIENTS recipe_ingredients uuid id PK uuid recipe_id FK, IDX varchar food_element_id IDX numeric required_volume FOOD_ELEMENTS->RECIPE_INGREDIENTS RECIPE_BOOK recipe_book uuid id PK varchar name text description boolean is_master timestamptz created_at RECIPE_BOOK->RECIPE_INGREDIENTS MENU_TEMPLATES menu_templates uuid id PK varchar name text description boolean is_master IDX timestamptz created_at MENU_ITEMS menu_items uuid id PK uuid menu_id FK varchar food_element_id numeric required_quantity MENU_TEMPLATES->MENU_ITEMS USER_MENU_ACTIVATIONS user_menu_activations uuid id PK uuid menu_id FK varchar home_group_id IDX varchar user_id varchar trace_id varchar status IDX varchar space_type timestamptz activated_at timestamptz updated_at MENU_TEMPLATES->USER_MENU_ACTIVATIONS

2.4 ER-модель. Домен ИИ-сервисов (AID)

В этой части декомпозированы структуры баз данных aid_db. Они отвечают за логи ИИ сервисов, и запросы отправленые на ручную модерацию непрошедшие: цензуру, обработку естественного языка (NLP), сканировании ОФД-чеков (OCR) или распознавание аудио-записи (VTT).

Security_MDM_Physical_Model cluster_aid_db СУБД: aid_db (Контур AID) MODERATION_TICKETS moderation_tickets uuid id PK varchar ticket_id UK varchar user_id varchar trace_id varchar status IDX text raw_text_draft varchar app_lang timestamptz created_at timestamptz updated_at ABUSE_VIOLATIONS abuse_violations uuid id PK varchar user_id IDX varchar trace_id varchar violation_type text raw_content numeric confidence_score timestamptz created_at IDX ABUSE_VIOLATIONS->MODERATION_TICKETS Асинхронный trace_id OCR_PROCESSING_LOGS ocr_processing_logs uuid id PK varchar trace_id IDX varchar user_id IDX text image_s3_url text raw_ocr_output varchar processing_status IDX integer execution_time_ms timestamptz created_at S3_RECEIPT_IMAGES bucket: bpds-inventory-receipt-images policy Private / Restricted access Presigned URLs (TTL 15m) OCR_PROCESSING_LOGS->S3_RECEIPT_IMAGES Ссылка image_s3_url VISION_YOLO_PROCESSING_LOGS vision_yolo_processing_logs uuid id PK varchar trace_id IDX varchar user_id IDX text image_s3_url jsonb detected_classes jsonb bounding_boxes integer execution_time_ms timestamptz created_at S3_PRODUCT_IMAGES bucket: bpds-inventory-product-images policy Private access Presigned URLs (TTL 15m) VISION_YOLO_PROCESSING_LOGS->S3_PRODUCT_IMAGES Ссылка image_s3_url UNRELIABLE_USER_LOGS unreliable_user_logs uuid id PK varchar user_id IDX varchar trace_id text audio_s3_url integer violation_count timestamptz detected_at IDX S3_VOICE_STREAMS bucket: bpds-inventory-voice-streams policy Private access Presigned URLs (TTL 15m) UNRELIABLE_USER_LOGS->S3_VOICE_STREAMS Ссылка audio_s3_url

2.5 ER-модель. Домен “цифрового холодильника” (INVENTORY)

В этой части декомпозированы структуры баз данных fridge_db, billing_db. Они отвечают за операционные таблицы движения ресурсов: учет запасов еды (остатков), чеки (store_receipts), контур приготовления (cooking_history), а также записи потребления (consumption_sessions) и порчи продуктов (waste_logs).

Inventory_View_Physical_Model cluster_fridge_db СУБД: fridge_db (Контур Холодильника / СУБД INVENTORY) FRIDGE_INVENTORY fridge_inventory uuid id PK varchar home_group_id IDX varchar food_element_id numeric quantity varchar trace_id timestamptz created_at IDX timestamptz updated_at V_CLIENT_FRIDGE_INVENTORY v_client_fridge_inventory (VIEW) uuid id varchar home_group_id varchar food_element_id varchar trace_id numeric real_db_quantity numeric masked_ui_quantity MASKED timestamptz created_at timestamptz updated_at FRIDGE_INVENTORY->V_CLIENT_FRIDGE_INVENTORY Построено на основе STORE_RECEIPTS store_receipts varchar receipt_id PK varchar home_group_id varchar shop_id numeric total_amount varchar trace_id IDX RECEIPT_ITEMS receipt_items int item_id PK varchar receipt_id FK text raw_input_name varchar resolved_product_id numeric quantity numeric price_per_unit STORE_RECEIPTS->RECEIPT_ITEMS COOKING_HISTORY cooking_history uuid id PK varchar home_group_id IDX varchar trace_id varchar dish_name varchar space_type numeric total_portions numeric remaining_portions jsonb spent_ingredients timestamptz created_at timestamptz updated_at WASTE_LOGS waste_logs uuid id PK varchar home_group_id IDX varchar user_id varchar trace_id varchar waste_reason IDX varchar space_type jsonb spent_items timestamptz created_at IDX CONSUMPTION_SESSIONS consumption_sessions uuid id PK varchar home_group_id IDX varchar user_id varchar trace_id varchar space_type timestamptz consumed_at IDX CONSUMPTION_ITEMS consumption_items uuid id PK uuid session_id FK varchar food_element_id numeric quantity_spent CONSUMPTION_SESSIONS->CONSUMPTION_ITEMS

2.6 ER-модель. Домен аналитики и аудита (PMA)

В этой части декомпозированы структуры баз данных affinity_db и bupar_db. Они отвечают за накопления и обработку аналитических метрик (OLAP) и сбор шагов бизнес-процесса для Process Mining.

Analytics_Core_Physical_Model cluster_affinity_db СУБД: affinity_db (affinity-service) cluster_bupar_db СУБД: bupar_db (bupar-audit-service) USER_AFFINITY user_product_affinity varchar home_group_id PK varchar master_product_id PK int score timestamptz last_interaction IDX AFF_PROD_REF affinity_product_reference varchar product_id PK int base_affinity_score REDIS_MATRIX_CACHE In-Memory Redis Matrix varchar redis_key PK varchar associated_product_id PK numeric sorted_score BUPAR_LOGS bupar_event_logs uuid event_id PK varchar case_id IDX varchar trace_id IDX varchar home_group_id varchar event_type varchar activity_name jsonb payload_details timestamptz event_timestamp USER_PRODUCT_AFFINITY USER_PRODUCT_AFFINITY USER_PRODUCT_AFFINITY->AFF_PROD_REF

3 Пример DDL-спецификации по ER-диаграмме

3.1 Пример структуры affinity_db и bupar_db

-- ============================================================================
-- СХЕМА АНАЛИТИЧЕСКОЙ СУБД РЕКОМЕНДАЦИЙ (affinity_db)
-- ============================================================================
CREATE DATABASE affinity_db;
\c affinity_db;

-- 1. Таблица разреженной матрицы предпочтений групп
CREATE TABLE user_product_affinity (
    home_group_id VARCHAR(50) NOT NULL,
    master_product_id VARCHAR(50) NOT NULL,
    score INTEGER NOT NULL CHECK (score BETWEEN 0 AND 100),
    last_interaction TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    PRIMARY KEY (home_group_id, master_product_id)
);

-- 2. Локальный кэш-справочник базовых весов (Read-модель репликации из MDM)
CREATE TABLE affinity_product_reference (
    product_id VARCHAR(50) PRIMARY KEY,
    base_affinity_score INTEGER NOT NULL CHECK (base_affinity_score BETWEEN 0 AND 100)
);

-- Индекс для ночного Крон-движка деградации весов (03:00)
CREATE INDEX idx_affinity_cron_decay ON user_product_affinity (last_interaction ASC) WHERE score > 10;

-- ============================================================================
-- СХЕМА АНАЛИТИЧЕСКОЙ СУБД PROCESS MINING (bupar_db)
-- ============================================================================
CREATE DATABASE bupar_db;
\c bupar_db;

CREATE EXTENSION IF NOT EXISTS "pgcrypto";

-- Плоский журнал логов событий (Event Log) для Process Mining
CREATE TABLE bupar_event_logs (
    event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    case_id VARCHAR(50) NOT NULL, -- Сквозной маркер партии/цепочки еды
    trace_id VARCHAR(50) NOT NULL, -- Ссылка на технический UUID трейсинга логов Loki
    home_group_id VARCHAR(50) NOT NULL,
    activity_name VARCHAR(100) NOT NULL, -- Шаги: PRODUCT_BATCH_PURCHASED, MANUAL_DISH_COOKED, FOOD_CONSUMED, FOOD_WASTED
    payload_details JSONB NOT NULL, -- Слепок физических параметров мутации
    event_timestamp TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Композитный индекс: критически важен для пакета bupar при сборке хронологических графов
CREATE INDEX idx_bupar_case_id_timeline ON bupar_event_logs(case_id, event_timestamp ASC);
-- Индекс для мгновенной фильтрации технического следа по trace_id шлюза Nginx
CREATE INDEX idx_bupar_logs_trace_id ON bupar_event_logs(trace_id);

SELECT 'ПРОЕКТИРОВАНИЕ ФИЗИЧЕСКОГО И СТРУКТУРНОГО СЛОЯ ЕДИНЫХ ER-ДИАГРАММ 6 СУБД ЗАВЕРШЕНО!' AS progress;

4 Окончание

В микросервисной архитектуре классические аналитические схемы («Звезда» и «Снежинка») не могут существовать в своем первозданном виде внутри операционных баз данных. Главный принцип микросервисов — Database-per-Service (у каждого сервиса своя изолированная СУБД). Из-за этого таблицы физически разрезаны по разным серверам (как в вашей системе auth_db, fridge_db, mdm_db). Сделать прямой SQL JOIN между таблицей фактов в одном сервисе и измерением в другом технически невозможно.Поэтому в микросервисной инфраструктуре применяются совершенно другие паттерны проектирования схем данных. Если кратко, их три:

  1. Это адаптация схемы «Звезда» под реалии микросервисов.

Сервис, которому нужна аналитика или быстрая выгрузка, не ходит в другие сервисы за справочниками. Вместо этого он слушает события из брокера сообщений (Kafka/RabbitMQ) и копирует (дублирует) нужные измерения к себе в базу.

  1. Сквозные ID-цепочки (Логическая «Снежинка»)

Таблицы не связаны физическими FOREIGN KEY, но содержат общие сквозные идентификаторы бизнес-ключей (trace_id, user_id, home_group_id, food_element_id). Каскадные связи «Снежинки» переносятся с уровня базы данных на уровень кода приложения (API Gateway или Бэкенд-оркестратор).

  1. Выделенное CQRS-хранилище (Read-модель)Паттерн разделения ответственности на чтение и запись (Command Query Responsibility Segregation).Суть: Операционные СУБД микросервисов вообще не занимаются построением сложных схем. Они оптимизированы только на быструю запись (OLTP). Все изменения (события) из всех микросервисов стримятся в одно общее аналитическое хранилище (DWH/Data Lake) — например, в ClickHouse, Greenplum или вашу СУБД аналитики процессов bupar_db.