Доменная модель DG: домены, владение и соглашения

Доменная модель в управлении данными (DG) — это структурированный подход к организации данных по бизнес-доменам, где каждый домен имеет явного владельца, ответственную сторону за качество и поддержку, а также соглашения, регламентирующие обмен данными между доменами. В рамках операционной модели DG домены становятся «модульными единицами» управления данными, которые можно разворачивать, масштабировать и модернизировать независимо, но при этом сохраняют единые принципы калибровки качества, политики доступа и управления рисками.

Эта глава объясняет, зачем нужны домены и владение данными, как формируются договорённости между доменами (data contracts), какие роли задействованы в модели владения, и как эти концепции переводить в реальные бизнес-процессы и техническую архитектуру. Мы рассмотрим теорию и приведём практические примеры с опорой на открытые инструменты (open-source) и отечественные (российские) решения, включая типовые сценарии внедрения, типовые артефакты и риск-менеджмент.

Ключевые идеи, которые вы возьмёте из этой главы:

домены как единицы ответственности за данные и их качество;
понятие владения (Data Owner, Data Steward, Data Custodian) и их роли в бизнес-процессе;
договорённости между доменами: Data Sharing, Data Access, Data Quality и Data Contract;
связь доменной модели с операционной моделью DG и RACI;
практические примеры реализации и архитектурные принципы на базе open-source и российских решений;
риски внедрения, их предупреждение и минимизация.

Что такое доменная модель DG

Доменная модель DG — это конкретизация структуры данных по бизнес-доменам, где каждый домен имеет:

четко обозначенного владельца данных (Data Owner);
кураторов данных (Data Steward) — контекстные специалисты по качеству, определению и использованию данных;
администраторов и операторов данных (Data Custodian) — технические лица, ответственные за хранение, доступ и эксплуатацию;
набор активов данных (Data Assets) и связанные с ними метаданные;
набор соглашений (Data Contracts/Agreements) с соседними доменами и потребителями данных.

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

Основные термины и роли

Data Owner (владелец данных): бизнес-персона, который отвечает за бизнес-правила, контекст и соответствие данных целям домена. Владелец принимает решения о целостности, доступности и использования данных в рамках бизнес-целей.
Data Steward (куратор данных): эксперт по данным, отвечающий за определение данных, их качества, семантику и устойчивость к изменениям. Обычно концентрируется на конкретном наборе атрибутов (полей) и правил валидации.
Data Custodian (администратор данных): технический исполнитель, который обеспечивает инфраструктуру, хранение, резервное копирование, безопасность и доступ к данным.
Data Product Owner (не всегда выделяется отдельно, но часто встречается в DG-ориентированной организации): владелец продукта данных — отвечает за набор услуг данных как продукта для потребителей внутри компании.
Data Asset: конкретный элемент данных или набор данных, например, таблица клиентской информации, датасет сделок, файл журналов событий.
Data Contract / Agreement: соглашение между доменами или между данными и потребителями, устанавливающее структуру, формат, частоту обновлений, ответственность за качество и правила доступа.
Canonical Data Model (каноническая модель данных): унифицированная, согласованная схема атрибутов и форматов, используемая для интеграции между доменами.
Data Lineage: происхождение и преобразование данных от источника к конечному потребителю.
Data Quality Rules: набор правил контроля качества для конкретного атрибута или набора атрибутов.
Data Classification и Privacy: категоризация данных по уровню конфиденциальности и соответствие требованиям законодательства.

Domain-driven подход к DG

Подход, основанный на доменах, вводит концепцию ограниченных контекстов (bounded contexts) не только в программной архитектуре, но и в управлении данными. Это позволяет:

снизить риск пересечения бизнес-правил между доменами;
ускорить локальные улучшения качества данных и правил;
облегчить внедрение изменений без разрушительного воздействия на соседние домены.

Взаимосвязь с RACI

RACI-модель становится эффективным инструментом для распределения ответственности в рамках доменной модели:

Responsible (Исполнитель): кто выполняет работу по данным конкретного актива;
Accountable (Ответственный): тот, кто несёт конечную ответственность за результат и прохождение согласований;
Consulted (Консультируемый): лица, чьи знания необходимы для выполнения задачи;
Informed (Информируемый): лица, которые должны быть уведомлены о ходе и результатах.

В контексте DG RACI связывает домены, активы, политики и соглашения с конкретными ролями и бизнес-процессами, обеспечивая ясность ответственности и ускоряя принятие решений.

Соглашения между доменами

Соглашения — важнейшее звено доменной модели. Ключевые типы:

Data Sharing Agreement (DSA): регламентирует обмен данными между доменами, включая формат, частоту обновления, ответственность за качество и безопасность.
Data Access Policy / Data Access Agreement: устанавливает, кто имеет доступ к каким данным и на каких условиях (роль, уровень допуска, срок действия доступа, аудит).
Data Quality Agreement: определяет требования к качеству данных, принципы мониторинга и ответственность за исправления.
Data Retention and Destruction Policy: сроки хранения, процедура уничтожения информации, соответствие регуляторным требованиям.
Data Contract: техническое соглашение между источником и потребителем данных, включая схему, типы данных, семантику и контрактные показатели.

Модель владения и входные данные

Эффективная доменная модель требует тщательной регистрации и актуализации следующих артефактов:

Domain Catalog: перечень доменов с их границами и контекстами;
Data Asset Catalog: активы внутри домена;
Ownership Map: матрица владения активами;
Data Contracts Registry: перечень соглашений между доменами;
Quality Rules Registry: правила качества и примеры проверок;
Lineage Registry: трассировка происхождения данных.

Как доменная модель поддерживает операционный DG

Структурная ясность: понятные границы доменов упрощают принятие решений и снизят конфликт при обмене данными.
Эффективная ответственность: четкие роли и RACI-модели позволяют быстро определить, кто отвечает за что.
Контроль качества: соглашения и правила качества поддерживают надежность данных.
Безопасность и соответствие: политики доступа и согласованные контракты упрощают соответствие требованиям.

Практические примеры

Ниже приведены два практических сценария: один на основе открытого стека инструментов (open-source), второй — с акцентом на российские решения и подходы к интеграции.

Пример 1: Open-source стек для DG

Архитектура (упрощённая схема):

Метаданные и каталог: Apache Atlas (каталог метаданных) или DataHub / Amundsen (каталоги данных).
Контроль доступа: Apache Ranger или Open Policy Agent (OPA).
Качество данных: Great Expectations.
Линейность данных: Atlas lineage / DataHub lineage.
Оркестрация и процессы: Apache Airflow.
Каталог активов и версии контрактов: собственный слой на Postgres или Loki-based store.
Аутентификация: Keycloak (OIDC/SAML).

ASCII-диаграмма архитектуры: Client apps -> DG API -> Metadata Catalog (Atlas/DataHub) -> Data Stores (Postgres/HDFS/S3) -> Processing (Airflow) -> Access Policy (Ranger/OPA)

Фрагменты конфигураций:

DomainDefinition.yaml (пример домена "Клиент")

domain:
  name: Client
  description: "Данные клиентов: профиль, история взаимоотношений, предпочтения."
  owner:
    name: Иванов Иван Иванович
    email: ivanov@example.com
  steward:
    name: Петрова Анна Сергеевна
    email: petrova@example.com
  dataAssets:
    - name: client_profile
      assetType: table
      schema: client_profile.json
      owner: ClientOwner
      contracts:
        - ClientDataShareToMarketing
      qualityRules:
        - not_null: ["customer_id"]
        - unique: ["customer_id"]

Data Contracts Registry (пример)

contracts:
  - name: ClientDataShareToMarketing
    sourceDomain: Client
    targetDomain: Marketing
    frequency: daily
    format: json
    schema: client_to_marketing_schema.json
    responsibilities:
      owner: Client
      recipient: Marketing
      qualityOwner: Client Steward

Data Access Policy (OPA-пример)

package dg.authz

default allow = false

# Разрешение на чтение клиентского профиля только для ролей "маркетинг" и "анализ"
allow {
  input.user_role == "marketing" 
  input.action == "read"
  input.resource == "client_profile"
}

Правила качества (Great Expectations)

import pandas as pd
import great_expectations as ge

df = pd.read_csv("client_profile.csv")
dataset = ge.from_pandas(df)

dataset.expect_column_values_to_not_be_null("customer_id")
dataset.expect_column_values_to_be_in_type_list("signup_date", ["datetime64[ns]"])
dataset.expect_column_values_to_be_unique("customer_id")

results = dataset.validate()

Таблица роли и ответственности (RACI для домена Client)

Роль	Ответственность	Примеры действий
Data Owner	Accountable за бизнес-целостность	Устанавливает правила использования, согласовывает новые поля
Data Steward	Responsible за качество и семантику	Определение значений, валидация правил
Data Custodian	Consulted/Responsible за инфраструктуру	Управление хранением, доступами, резервным копированием
Data Consumer	Informed	Использование данных в отчетах и продуктах

Пример 2: Российские решения и локализация подхода

Контекст: крупная отечественная компания строит DG на базе открытых инструментов, адаптированных под требования российского законодательства (ФЗ-152, обработка персональных данных, централизованные сервисы управления метаданными). Архитектура опирается на локализацию и безопасность данных, но сохраняет гибкость открытого стека.

Архитектура:

Каталог метаданных: локальный сервис на базе open-source каталога, дополненный отечественным адаптером аутентификации и локализованной политикой доступа.
Каталог активов: PostgreSQL/ClickHouse с API-SOAP/REST для интеграций.
Политики доступа: отечественный движок политики на базе OPA/модуля, интегрированного с локальным хранением пользователей.
Контракты между доменами: регламентируются внутренними документами и соответствуют требованиям ФЗ-152, обобщение на Data Sharing и Data Access Agreement.
Контроль качества: внутренние конструкторы правил на основе Great Expectations или локальных аналогов, с возможностью запуска в CI/CD.
Оркестрация: Apache Airflow/Argo Workflows с расширенной логикой аудита и соответствия.

Архитектурный пример конфигурации: DomainDefinition.yaml (пример «Контракты» и «Права доступа»)

domain:
  name: Transactions
  owner: "Банковский владелец данных"
  steward: "Куратор качества транзакций"
  dataAssets:
    - name: transactions
      schema: transactions_schema.json
      contracts:
        - TransactionsDataShareToAnalytics
      accessPolicy:
        - role: "аналитик"
          permissions: ["read", "query"]
        - role: "оператор"
          permissions: ["read_only"]

Data Contract (регистрация контракта)

contracts:
  - name: TransactionsDataShareToAnalytics
    sourceDomain: Transactions
    targetDomain: Analytics
    frequency: daily
    format: parquet
    schema: transactions_to_analytics_schema.json
    compliance:
      retention: 180
      encryption: "AES-256"
      piiHandling: "masked"

Пример политики доступа в стиле OPA

package dg.access

default allow = false

allow {
  input.user_role == "аналитик"
  input.action == "read"
  input.resource == "transactions"
}

Пример канонической модели (управление семантикой): Структура канонических данных может выглядеть как: { "domain": "Transactions", "fields": { "transaction_id": {"type":"string", "description":"Идентификатор транзакции"}, "customer_id": {"type":"string", "description":"Идентификатор клиента"}, "amount": {"type":"decimal", "description":"Сумма"}, "date": {"type":"date", "description":"Дата операции"} } }

Таблица доменов и владельцев (упрощённая)

Домeн	Владелец	Куратор	Пример активов	Основные контракты
Клиенты	Директор по данным бизнеса	Аналитик по клиентам	client_profile, client_addresses	ClientDataShareToMarketing, ClientPrivacyPolicy
Сделки	Руководитель направления продаж	Специалист по данным сделок	transactions, deals_log	TransactionsDataShareToAnalytics, TransactionsPrivacyPolicy

Архитектура данных и каноническая модель

Domain Catalog: перечень доменов, их контекстов и прав доступа.
Data Asset Catalog: активы внутри домена с полями: name, type, schema, owner, lineage, qualityRules.
Data Contract Registry: набор соглашений между доменами, связанных с активами и частотой обновления.
Lineage Registry: трассировка происхождения данных и их преобразований.
Quality Rules Registry: формализованные правила качества с тестами и результатами.

Пример схемы моделирования домена

Domain: Client
Assets: client_profile (таблица), client_addresses (таблица)
Fields: customer_id (PK), name, email, phone, address_id
Owners: Data Owner, Data Steward
Contracts: ClientDataShareToMarketing, ClientPrivacyPolicy

Технические артефакты

YAML/JSON спецификации домена и активов
CSV/JSON-форматы для экспорта метаданных
Архитектурная документация (архитектурные решения по DG)
Политики доступа в формате OPA/пользовательские политики
Правила качества данных (например, в Great Expectations), аудиты и отчёты

Пример структуры артефактов

DomainDefinition.yaml
DataAssets.yaml
Contracts.yaml
AccessPolicies.yaml
QualityRules.yaml
Lineage.json

Примеры кода и конфигураций

YAML-фрагмент домена

domain:
  name: Product
  description: "Данные о продуктах и их атрибутах"
  owner:
    name: "Сидоров Сергей"
    email: sidov@example.com
  steward:
    name: "Ковальчук Мария"
    email: kovalychuk@example.com
  dataAssets:
    - name: product_catalog
      assetType: table
      schema: product_catalog.json
      owners: ["ProductManager"]
      contracts: ["ProductDataShareToMarketing"]

Пример канонической схемы и атрибутов

{
  "domain": "Product",
  "fields": {
    "product_id": {"type": "string", "description": "Уникальный идентификатор продукта"},
    "name": {"type": "string", "description": "Название продукта"},
    "category": {"type": "string", "description": "Категория продукта"},
    "price": {"type": "decimal", "description": "Цена"},
    "availability": {"type": "boolean", "description": "Доступность"}
  }
}

Пример RACI-матрицы по активу product_catalog

Актив	Data Owner	Data Steward	Data Custodian	Data Consumer
product_catalog	A	C	R	I
product pricing	A	R	C	I

Таблица правил качества (пример)

Правило	Описание	Применение	Метрика
not_null(customer_id)	customer_id не может быть пустым	Для клиента	количество пустых значений в наборе
unique(customer_id)	customer_id уникален	Для клиента	доля уникальных значений

Инструменты и примеры реализации

Open-source решения:

Apache Atlas или DataHub (каталог метаданных и линейность)
Amundsen (каталог данных)
Apache Ranger или OPA (управление доступом)
Great Expectations (правила качества)
Apache Airflow (оркестрация)
Elasticsearch/ClickHouse (модели поиска и аналитики по метаданным)
Keycloak (аутентификация/авторизация)

Российские решения и адаптации:

локализованные каталоги метаданных на базе открытого стека с отечественным адаптером аутентификации
внутренние сервисы хранения и обработки метаданных, соответствующие требованиям ФЗ-152 и локализации данных
отечественные интеграционные компоненты для политики доступа и аудита, интегрируемые с существующими системами бухгалтерии и ERP

Важные принципы миграции и интеграции:

миним viable DG (MVDG): начать с малого набора доменов и активов, быстро получить первые результаты
постепенная интеграция контрактов между доменами
обеспечение аудита и мониторинга для доказательства соответствия

Риски и ограничения внедрения

Неправильно сформулированные границы доменов: риск конфликтов, дублирования и перекрестного владения.
Неустойчивые владельцы данных: отсутствие устойчивых ролей приводит к усталости команды и задержкам в принятии решений.
Неполный набор контрактов: отсутствие соглашений между доменами вызывает недопонимание правил обмена и ответственности в случае ошибок.
Слабая трансформация процессов: DG требует изменения бизнес-процессов; без поддержки руководства внедрение затягивается.
Проблемы качества данных и трассируемости: без качественных правил и lineage данные могут быть непредсказуемыми и трудны для аудита.
Регуляторные риски: ФЗ-152 (персональные данные), требования к локализации и хранению данных, санкции и т.д.
Технологический риск: избыток слоёв абстракций может повлиять на производительность и сложность поддержки.
Затраты и изменение культуры: DG требует времени и изменений в культуре компании, чтобы данные рассматривались как продукт, а не как месседжи в отчётности.

Меры снижения рисков:

начальная фокусировка на 2–3 домена с четкими бизнес-целями;
закрепление руководством роли Data Owner и поддержка на уровне руководителя;
формализация Data Contracts и данных lineage с простым, понятным набором правил;
создание пилотной системы мониторинга качества и доступа;
внедрение политики изменения: небольшие, повторяемые итерации, быстрые результаты;
соблюдение нормативных требований: регулярные аудиты, документация, соответствие ФЗ-152 и локальным требованиям.

Выводы

Доменная модель DG — это фундаментальный элемент управляемой архитектуры данных, которая позволяет бизнесу владеть данными на уровне доменов, улучшать качество, управлять доступом и формировать прозрачные соглашения между участниками.
Важны четкие роли и ответственности (Data Owner, Data Steward, Data Custodian) и хорошо продуманные Data Contracts.
Архитектура DG должна сочетать теоретические принципы Domain-Driven Design с реальной операционной моделью, чтобы поддерживать быстрые решения и устойчивое развитие.
Open-source и российские решения позволяют построить эффективную DG-модель без чрезмерной зависимости от одного поставщика, при этом обеспечивая необходимые требования по безопасности и конфиденциальности.
Начинайте с MVP: ограничьте число доменов, создайте базовые контракты, внедрите ключевые правила качества и доступности — затем постепенно масштабируйте.

FAQ (Вопросы и ответы)

1) Что такое доменная модель DG и зачем она нужна?

- Она структурирует данные по бизнес-доменам, назначает ответственных и определяет правила обмена данными между доменами. Это помогает бизнесу управлять качеством данных, безопасностью и соответствием регуляторным требованиям, ускоряет принятие решений и упрощает встраивание DG в бизнес-процессы.

2) Кто такие Data Owner, Data Steward и Data Custodian и как их выбрать?

Data Steward — эксперт по данным, обеспечивает качество и семантику.
Data Custodian — технический исполнитель по инфраструктуре, безопасностям и доступу.
Выбор осуществляется с учётом масштаба домена и формата бизнес-процессов; часто это руководитель подразделения, аналитик по данным и IT-оператор.

3) Как связать домены с бизнес-процессами и BPMN?

- Доменные контексты должны встроиться в бизнес-процессы через роли RACI и Data Contracts. В BPMN можно добавлять задачи по управлению данными (например, "проверка качества данных", "прохождение контракта между доменами") и назначать соответствующим ролям.

4) Какие договоренности нужны между доменами и какие данные они охватывают?

Data Access Policies — кто и как может использовать данные;
Data Quality Agreements — требования к качеству;
Data Contracts — технические детали передачи, формат, частота обновления, ответственность;
Data Retention и Privacy Policies — хранение и удаление данных.

5) Какие open-source инструменты подходят для DG?

Amundsen (каталог данных);
Apache Ranger / OPA (контроль доступа);
Great Expectations (правила качества);
Apache Airflow (оркестрация);
Keycloak (аутентификация и SSO).

6) Как внедрять DG в российском контексте: требования и ограничения?

Архитектура может локализовать каталоги метаданных и предоставить отечественные адаптеры аутентификации и политик доступа.
Важно соблюдать требования к аудиту и хранению журналов действий.

7) Какие риски наиболее критичны и как их снижать?

Отсутствие устойчивого владения — закрепляйте Data Owner на уровне руководства;
Недостаточные контракты — создавайте базовый набор контрактов и развивайте их;
Неполный контроль качества — внедрите линейки тестов и мониторинг; регулярные аудиты;
Регуляторные риски — тесная связь с комплаенсом и юридическим отделом.

8) Как измерять успех DG?

Оценка удовлетворенности потребителей данных, скорость реагирования на запросы доступа, доля активов с контрактами.

9) Можете ли привести пошаговый план внедрения?

Шаг 2: создайте Domain Catalog и первые Data Contracts;
Шаг 3: внедрите базовые правила качества и политику доступа;
Шаг 4: интегрируйте каталог с регистром активов в существующие BI/ETL-процессы;
Шаг 5: проведите пилот, измерьте KPI и расширяйте покрытие доменов;
Шаг 6: переносите к более зрелой модели с добавлением новых доменов и контрактов.

10) Какие шаги помогают ускорить внедрение RACI в DG?

Внедрение RACI-матриц в артефкты DG (DomainDefinition, DataAssets, Contracts);
Регулярные собрания доменных владельцев и стейкхолдеров для утверждения изменений.

← Предыдущая статья

Организационные структуры DG

Следующая статья →

Роли, ответственность и RACI (RASCI) в DG