「ドメインがデータを所有する」というデータメッシュの第1原則は、聞いただけだと当たり前に聞こえます。実装の段になって悩むのは「そもそもうちのドメインってどう切るんですか？」です。営業組織のままなのか、業務プロセス単位なのか、システム境界なのか。境界の引き方ひとつで、後の運用が大きく変わります。
幸い、ソフトウェアエンジニアリングには「DDD（ドメイン駆動設計）」という長年の知見があります。これをデータに応用するのが、Domain-driven Dataの考え方です。Bounded Context・3種類のデータ製品といった具体に降ろして整理します。
ドメインとは何か
ドメインは「業務的に意味のある一貫した領域」で、組織図と一致しないことがあります。たとえば「注文管理」というドメインには、営業・物流・経理の関わりがあるが、それらを横断して「注文」という概念で一貫した責任を持つ単位、というイメージです。
| ドメインの切り方 | 例 |
|---|---|
| 業務プロセス単位 | 注文管理、在庫管理、顧客管理、配送管理 |
| 事業セグメント単位 | B2B事業、B2C事業、サブスクリプション事業 |
| 顧客ジャーニー段階 | 獲得、活性化、収益化、リテンション |
正解はひとつではなく、組織が「データを通じて何を実現したいか」で変わります。ドメインの境界が、データの所有と責任の境界になります。
Bounded Context：DDDからの応用
DDDの中核概念のひとつが「Bounded Context」です。「同じ言葉でも、文脈によって意味が違う」ことを認め、境界を明確にする考え方です。データにも同じ概念が使えます。
たとえば「顧客」という言葉が、ドメインによって違う意味を持ちます。営業ドメインでは「商談相手の企業＋担当者」、物流ドメインでは「配送先」、サポートドメインでは「お問い合わせをくれる人」。同じ顧客IDでも、文脈によってモデルは違います。Bounded Contextを引かずに「全社の顧客マスタ」を作ろうとすると、すべてのドメインで使いにくいスキーマになります。
3種類のデータ製品
Zhamak Dehghaniは、データメッシュの中でData Productを3つに分類します。詳細はData Product とはで扱いますが、ドメイン境界との関係を先に整理します。
| タイプ | 由来 | 例 |
|---|---|---|
| Source-aligned | ソースシステムに対応 | 注文管理ドメインの「注文イベントストリーム」 |
| Aggregate | 複数Source-alignedを統合 | 顧客360ビュー（営業・サポート・物流の顧客情報統合） |
| Consumer-aligned | 消費者の用途に最適化 | マーケティング分析向けの「顧客セグメント」 |
各ドメインは、自分の「ソースに近い」Data Productと、消費者向けの「アグリゲート」のどちらか、または両方を所有します。誰がどのタイプを所有するかが、組織の責任分担の核心です。
境界引きの実務的アプローチ
- ステップ1：既存の主要なデータパイプラインとダッシュボードを棚卸しする
- ステップ2：それらが扱う「業務概念」を抽出する（注文、商品、顧客等）
- ステップ3：業務概念ごとに「誰がいちばん詳しいか」「誰が変更責任を持つか」を業務側にヒアリング
- ステップ4：似た概念がまとまるドメインを暫定的に定義する（3〜7ドメイン程度から始める）
- ステップ5：暫定ドメインで1〜2のData Productを試行し、境界の妥当性を検証する
最初から完璧な境界を引こうとすると、永遠に決まりません。「暫定で動かす→運用で違和感が出たら調整」のサイクルで、現実的なドメイン境界を形成します。
中央集権からの移行パターン
| 状況 | 移行アプローチ |
|---|---|
| 1つのデータエンジニアチームが全部やっている | 業務側にデータエンジニア候補を移籍or兼任で配置 |
| 業務側にBI担当はいるがデータ加工はできない | 共通プラットフォーム（dbtテンプレート等）で加工を簡素化 |
| ドメインによって成熟度に差がある | 成熟ドメインから1〜2個でパイロット |
| 業務側の予算意識が薄い | Data Productを契約モデル化（SLA・サポート明文化） |
向く・向かない場面
- 向く：複数の独立した業務領域がある、中央データチームが捌けない量のリクエスト、業務側にデータ素養がある人材を配置できる
- 向かない：単一業務でドメイン分割の意味がない、業務側にデータ人材がいない、組織変革に経営の支援がない
まとめ
- ドメインは「業務的に一貫した領域」で、組織図とは一致しないことがある。
- DDDのBounded Contextをデータに応用し、「同じ言葉の文脈による違い」を認める。
- Data Productは Source-aligned / Aggregate / Consumer-aligned の3種類。
- 境界引きは「暫定で動かして調整」のサイクル。完璧主義は罠。
- 移行は成熟ドメインから1〜2個のパイロットで始める。
全体像はデータメッシュ実装の現実、隣接はData Product とは・Federated Governance。ドメイン境界の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. ドメインの数はいくつが適切ですか？
A. 中堅企業で5〜10、大企業で15〜30程度が一般的です。少なすぎると「中央集権の言い換え」、多すぎると統治コストが爆発します。「1ドメインに2〜10名のデータ関係者」が回せる規模感が目安です。
Q. ドメイン境界は後から変えられますか？
A. 変えられますが、コストがかかります。境界変更は、Data Productの所有権変更、SLA見直し、ドキュメント書き換えが伴います。だからこそ「最初から完璧」を目指さず、「暫定で動かして調整」のサイクルで、変更コストが受容範囲のうちに学習を進めるアプローチが現実的です。
Q. dbtの層分けとドメインは関係しますか？
A. 関係します。各ドメインがdbtプロジェクト（またはサブプロジェクト）を持ち、自分のドメインのSilver/Goldを管理する構成がよくあります。Source-alignedはSilverに近く、Consumer-alignedはGoldに近い、というマッピングも一般的です。dbtの基本はdbt実装ガイド、メダリオンはメダリオンアーキテクチャ解説を参照してください。