Раздел 3 · Модуль 1

Data Governance

Ядро системы: универсальная мета-модель «всё есть объект», версионирование, статусы, аудит, граф зависимостей и ролевой доступ.

Корень: backend/. FastAPI, роутеры под /api/v1 (app/modules/data_governance/api.py + app/modules/auth_api.py).

3.1 · Мета-модель (физические таблицы)

Всего ~7 таблиц (app/db/models.py). Никаких выделенных таблиц domains/terms/fsd нет — всё это классы и объекты.

Таблица	Назначение
`meta_class`	Реестр классов: `code` (уник.), `name`, `parent_class_id` (иерархия), `validation_schema` (JSON Schema), `ui_schema`, `is_abstract`, `is_system`.
`meta_object`	Экземпляр любой сущности: `class_id`, `code`, `name`, `properties` (JSON), `relations` (JSON), `version`, `parent_object_id`, `previous_version_id`, `status`. Уникальность `(class_id, code, version)`.
`meta_object_history`	Append-only снимки (`action`, `payload`, `actor`).
`meta_object_relation`	Нормализованные рёбра графа: `source`, `target`, `relation_type`, `properties.label`.
`meta_object_audit`	Аудит: `old_values`/`new_values`, `changed_by`, `reason`, `ip_address`, `user_agent`.
`meta_object_workflow`	Трекинг процессов: `process_instance_id`, `current_task`, `started_at`/`completed_at`.
`app_setting`	key/value JSON: конфиг сайдбара, ролей, пользователей, прав редактирования классов.

Все PK — строковые UUID. Поиск объектов выполняется через LIKE и фильтры.

3.2 · Классы объектов

Системные классы: DOMAIN, TERM, FSD, BRD, DQLA, DQ_CHECK, ORGANIZATION, ORG_TYPE, REGION и др. Каждый класс несёт свою JSON Schema для валидации properties его объектов.

3.3 · API (ключевое)

GET    /governance/summary                 — метрики дашборда
GET    /classes            POST /classes    (ADMIN)
GET    /classes/{code}     PUT/DELETE /classes/{code}  (ADMIN)
POST   /objects                            — создать объект
GET    /objects/search                     — q, class_code, domain_id, status, limit, offset
GET    /objects/{id}                       — (?include_history)
PUT    /objects/{id}                       — (?create_new_version)
DELETE /objects/{id}                       — soft-archive (ADMIN)
POST   /objects/{id}/status                — переход статуса
GET    /objects/{id}/lineage               — direction, depth 1..10
GET    /domains/{id}/export                — только format=json (иначе 501)

Auth-роутер: /auth/test-users, /auth/test-token/{username}, админ-конфиги /admin/roles, /admin/users, /admin/sidebar-config, /admin/class-edit-roles, /admin/form-builder-settings.

3.4 · Валидация и «полнота»

Отдельного движка качества/health-score в DG нет. Есть:

Schema-валидация при записи (_validate_object_properties): обязательные поля, типы, ссылочная целостность для полей типа meta_class. Ошибки → HTTP 422 со списком {field, message}.
Метрика покрытия доменов в get_summary: по домену domain_coverage = число терминов vs terms_plan_count → процент описанности (виджет «Уровень описания доменов данных»).
DQLA/DQ_CHECK в DG — просто классы-контейнеры; логика исполнения живёт в Task Manager (см. DQ Checks).

3.5 · Lineage (граф зависимостей)

get_lineage — обход в ширину (BFS) с ограничением по depth и дедупликацией. Три источника рёбер:

parent_child — из meta_object.parent_object_id.
property_ref — из полей класса типа meta_class; для FSD термины извлекаются из properties.blocks[].terms[].term_id (label «Блок: {имя}»).
relation — из таблицы meta_object_relation.

Рисуется на Vue Flow: колоночная раскладка (предки слева, потомки справа), цвет узла по классу, цвет ребра по типу связи, пошаговое раскрытие по 10 соседей, подсветка выбранного узла.

3.6 · Режимы сборки фронтенда

router.ts выбирает один из трёх наборов маршрутов на этапе сборки Vite:

VITE_ADMIN_MODULE=true → админ-модуль: только /classes, /admin/*. Неадминов гвард разлогинивает.
VITE_DG_MODULE=true → DG-only: /, /objects, /approvals, /journey, /submission/dq-rules.
иначе → полный портал: всё выше + /form-builder/* и /submission/* (iframe-обёртки).

3.7 · Ролевая модель и доступ

Механизм: самописный HS256 JWT. Пароля нет — токены выдаёт /auth/test-token/{username} (демо-режим).
Роли: VIEWER EDITOR APPROVER ADMIN SUPER_ADMIN + модульные (DOMAIN_EDITOR, TERM_EDITOR, FSD_EDITOR, DATA_MANAGER, SUBMISSION_*…). ROLE_SCOPES мапит роли → скоупы (dg:read, dg:editor, dg:approve, dg:admin).
Два уровня контроля: маршрутный require_roles("ADMIN") и класс-ориентированный (editable_class_codes_for_roles / readable_class_codes_for_roles). Поиск фильтруется по читаемым классам.
Кэш (core/cache.py) — на Redis; включается заданием redis_url.

3.8 · Seed-данные

scripts/seed_mock_data.py: 3 системных класса (DOMAIN/TERM/FSD), 2 домена (TAXATION, REPORTING), ~1000 терминов, 1 FSD (TAX_FORM_FSD). Все объекты — со статусом approved. Пользователи/роли этим скриптом не сеются (они в app_setting).