ドメイン指向のデータオーナーシップ
田中VPoE「Data Meshの第一原則『ドメイン指向のデータオーナーシップ』を実現するには、まずドメインの境界を正しく定義する必要がある。」
あなた「マイクロサービスの境界設計と似ていますね。」
田中VPoE「その通り。DDDの境界付けられたコンテキスト（Bounded Context）の考え方が使える。データの世界に適用してみよう。」
ドメインの境界を定義する
ドメイン分割の考え方
Data Meshにおけるドメインは、ビジネスの組織構造に沿って定義します。
NetShop社のドメイン例：
[注文ドメイン]
データ：注文、注文明細、決済、配送
[顧客ドメイン]
データ：顧客プロフィール、会員ランク、ポイント
[商品ドメイン]
データ：商品マスタ、カテゴリ、在庫、価格
[マーケティングドメイン]
データ：キャンペーン、広告効果、アクセスログ
[カスタマーサポートドメイン]
データ：問い合わせ、FAQ、満足度3種類のデータ
各ドメインが扱うデータは3つに分類されます：
| 種類 | 説明 | 例 |
|---|---|---|
| ソース整合データ | ドメインの業務システムから生まれるデータ | 注文トランザクション |
| ドメイン整合データ | ドメイン内で加工・集約されたデータ | 日次売上集計 |
| 消費者整合データ | 特定の消費者のニーズに合わせたデータ | マーケ向け顧客セグメント |
データオーナーの役割と責任
データプロダクトオーナー
各ドメインにデータプロダクトオーナーを配置します。
| 責任 | 内容 |
|---|---|
| データの品質保証 | SLAに基づくデータ品質の維持 |
| メタデータの管理 | ビジネス定義、スキーマ、リネージの管理 |
| 消費者対応 | データ消費者のニーズの把握と対応 |
| セキュリティ | データのアクセス制御と分類 |
| 進化の管理 | スキーマの変更管理（後方互換性の維持） |
ドメインチームの構成
Data Meshにおけるドメインチームは、データに関する責任も持ちます：
ドメインチーム構成例：
[注文ドメインチーム]
├── プロダクトマネージャー（1名）
├── バックエンドエンジニア（3名）
├── データエンジニア（1名） ← ドメインにデータ人材を配置
├── データアナリスト（1名） ← ドメインにデータ人材を配置
└── QAエンジニア（1名）従来型とData Mesh型の組織比較
従来型：
[営業チーム] [マーケチーム] [サポートチーム]
↓ データリクエスト ↓
[中央データチーム]
├── データエンジニア ×5
└── データアナリスト ×3
Data Mesh型：
[営業チーム + データ人材]
[マーケチーム + データ人材]
[サポートチーム + データ人材]
↓ プラットフォーム利用 ↓
[プラットフォームチーム]
└── プラットフォームエンジニア ×3ドメイン間のデータ連携
インターフェース契約
ドメイン間でデータを共有する際は、インターフェース契約を明示的に定義します。
# 注文ドメインのデータプロダクト契約例
name: "daily_orders"
version: "2.0"
owner: "orders-team"
description: "日次の注文集計データ"
schema:
fields:
- name: order_date
type: DATE
description: "注文日"
- name: total_orders
type: INTEGER
description: "注文件数"
- name: total_amount
type: DECIMAL
description: "注文金額合計（税込）"
sla:
freshness: "毎日AM7:00までに更新"
availability: "99.5%"
quality:
completeness: ">= 99%"
accuracy: ">= 99.9%"
consumers:
- marketing-team
- finance-teamデータの共有パターン
| パターン | 説明 | 適するケース |
|---|---|---|
| API経由 | RESTまたはgRPCでリアルタイムに取得 | 少量・リアルタイム |
| イベントストリーム | Kafka等でイベントを配信 | リアルタイム・非同期 |
| 共有データストア | DWH上の共有テーブルとして公開 | バッチ分析・大量データ |
| データ連携ジョブ | ETLで定期的にコピー | レガシーシステム連携 |
オーナーシップ移行の進め方
Phase 1：現状把握（1ヶ月）
- 既存データ資産のドメインへのマッピング
- 現在のデータフローの可視化
- ドメインごとのデータ人材の棚卸し
Phase 2：パイロット（2ヶ月）
- 最も成熟した1ドメインで試行
- データプロダクトオーナーの任命
- インターフェース契約の策定
Phase 3：段階的移行（6ヶ月〜）
- 他ドメインへの順次拡大
- ドメインチームへのデータ人材の配置
- プラットフォームの整備
まとめ
| 項目 | ポイント |
|---|---|
| ドメイン境界 | ビジネスの組織構造に沿って定義 |
| 3種類のデータ | ソース整合、ドメイン整合、消費者整合 |
| データプロダクトオーナー | 各ドメインにデータの品質と提供の責任者を配置 |
| インターフェース契約 | スキーマ、SLA、消費者を明示的に定義 |
チェックリスト
- ドメインの境界を定義する方法を説明できる
- 3種類のデータの違いを理解している
- データプロダクトオーナーの役割を説明できる
- インターフェース契約に含まれる要素を挙げられる
次のステップへ
ドメイン指向のデータオーナーシップを学びました。次は、データプロダクトの設計と構築方法を学びましょう。
推定読了時間：30分