データ ドメイン

データ メッシュは基本的に、分散化とドメインへの責任の分散に基づいています。 ビジネスのこの部分を本当に理解しているなら、関連するデータを管理してデータの正確性を確保するための最適な位置につけています。 これはドメイン指向のデータ所有権の原則です。

ドメイン指向のデータ所有権を推進するには、まずデータ アーキテクチャを分解する必要があります。 データ メッシュの創設者 Zhamak Dehghani は、データ ドメインの識別に役立つ便利な方法として、ソフトウェア開発へのドメイン駆動設計 (DDD) アプローチを推進しています。

データ管理に DDD を使用することの難しさは、DDD のもともとの使用例が、ソフトウェア開発の状況で複雑なシステムをモデル化することだったことにあります。 これはもともとエンタープライズ データをモデル化するために創り出されたものではなく、データ管理の専門家にとって、方法は抽象的で技術的な場合もあります。 また、DDD に関する理解不足もよくあります。 専門家は、概念が難しすぎて把握できなかったり、ソフトウェア アーキテクチャまたはオブジェクト指向プログラミングの例を自分のデータ環境に投影しようとしたりします。 この記事では DDD を理解して使用できるようにするために、実践的なガイダンスと明確なボキャブラリを示します。

Domain-Driven Design

ドメイン駆動設計は、Eric Evans によって提唱されたもので、大規模な組織の複雑なシステムを記述するのに役立つソフトウェア開発をサポートするための方法です。 DDD は、その上位レベルの慣行の多くが、マイクロサービスなどの最新のソフトウェアおよびアプリケーションの開発アプローチに影響を与えているという理由で広く普及しています。

DDD では、境界付きコンテキスト、ドメイン、サブドメインが区別されます。 ドメインは、対処する必要がある問題空間です。 これらは知識、行動、法律、活動が集まる領域です。 ドメイン内の意味的結合や、コンポーネントまたはサービスの間の動作の依存関係があるのがわかります。 ドメインのもう 1 つの側面は、コミュニケーションです。 チーム メンバーは、全員が効率的に作業できるように、チーム全体が共有する言語を使用する必要があります。 この共有言語は、"ユビキタス言語" または "ドメイン言語" と呼ばれています。

ドメインは、複雑さを管理しやすくするためにサブドメインに分解されます。 この一般的な例として、「AI/ML のデータ メッシュを運用化する」に示されているように、1 つのドメインを、ビジネス上の 1 つの特定の問題にそれぞれ対応するサブドメインに分解することが挙げられます。

すべてのサブドメインが同じというわけではありません。 たとえば、ドメインをコア、汎用、またはサポートのいずれかに分類できます。 コア サブドメインが最も重要です。 これらは組織を独特のものにする、秘伝のソースであり食材です。 汎用サブドメインは特有のものではなく、通常は既製の製品で簡単に解決できます。 サポート サブドメインは、競争上の優位性をもたらすものではありませんが、組織の運営を継続するために必要で、たいていは複雑ではありません。

境界付きコンテキストは、論理 (コンテキスト) 境界です。 これらはシステムとアプリケーションの設計というソリューション空間に焦点を当てています。 これは、ソリューション空間に焦点を当てることが理にかなっている領域です。 DDD 内では、これにはコードやデータベースの設計などが含まれます。 ドメインと境界付きコンテキストの間では、調整があってよく、この 2 つを結びつける厳格な規則はありません。 境界付きコンテキストは、本来技術的なものであり、複数のドメインとサブドメインにまたがることができます。

ドメイン モデリングに関する推奨事項

データの民主化の概念としてデータ メッシュを採用し、柔軟性を高めるためにドメイン指向のデータ所有権の原則を実装した場合、これは実際にどのように機能するでしょうか。 エンタープライズ データ モデリングからドメイン駆動設計モデリングへの移行はどのようなものでしょうか。 データ管理について DDD からどのような教訓を得ることができるでしょうか。

問題空間の機能的なビジネス分解を行う

自分のチームがデータをエンド ツー エンドで操作できるようにする前に、スコープを確認し、対処しようとしている問題空間について理解します。 技術的な実装の細部に飛び込む前に、まずこの仕事を行うことが重要です。 これらの問題空間の間に論理的な境界を設けると、責任が明確になり、正しく管理できるようになります。

問題空間をグループ化するときは、ビジネス構造を見てください。 ビジネス構造の内部には、ビジネス機能、つまりビジネスが特定の目的や成果を達成するために所有または交換する能力または生産能力があります。 この抽象化により、組織の戦略的なビジネス目標や目的に合わせて、データ、プロセス、組織、テクノロジが特定のコンテキストにひとまとめにされます。 ミッションとビジョンを達成するために必要と思われる機能領域は、ビジネス機能マップに示されます。

次のモデルでは、架空の会社 Tailwind Traders の機能分解を確認できます。

Tailwind Traders は、成功を収めるために、ビジネス機能マップに一覧表示されているすべての機能領域をマスターする必要があります。 Tailwind Traders では、たとえばオンラインまたはオフラインのチケット管理システムの一部としてチケットを販売したり、パイロット管理プログラムの一部としてパイロットが飛行機を飛ばせるようにしたりする必要があります。 この会社は一部の活動を外部委託しつつ、他の活動を業務の中核として維持することができます。

実際に観察されるのは、ほとんどの人がビジネス機能を中心に編成されるということです。 同じビジネス機能に従事する人は、同じボキャブラリを共有します。 アプリケーションとプロセスにも同じことが当てはまります。アプリケーションとプロセスは通常、それらによってサポートされるアクティビティの凝集度に基づいて適切に調整され緊密に連結されます。

ビジネス機能のマッピングは申し分ない出発点ですが、話はここで終わりではありません。

ビジネス機能をアプリケーションとデータにマップする

エンタープライズ アーキテクチャをより適切に管理するために、ビジネス機能、境界付きコンテキスト、アプリケーションを調整します。 これを行うときは、いくつかの基本原則に従うことが重要です。

ビジネス機能はビジネス レベルに維持され、抽象的なままにする必要があります。 これらは組織が行う内容を表し、問題空間を対象とします。 ビジネス機能を実装すると、特定のコンテキストの実現 (機能インスタンス) が作成されます。 ソリューション空間内のこのような境界内で複数のアプリケーションとコンポーネントが連携して、特定のビジネス価値が提供されます。

特定のビジネス機能に合わせたアプリケーションとコンポーネントは、他のビジネス機能に合わせたアプリケーションから切り離された状態に維持されます。これは、これらは異なるビジネス上の懸念事項に対処するためです。 境界付きコンテキストは、ビジネス機能から派生し、ビジネス機能に排他的にマップされます。 これらはビジネス機能の実装の境界を表し、ドメインのように振る舞います。

ビジネス機能が変更されると、境界付きコンテキストは変更されます。 ドメインと、対応する境界付きコンテキストの間で完全に調整されることが望ましいのですが、後のセクションで説明するように、現実は理想としばしば異なります。

機能マッピングを Tailwind Traders に投影した場合、境界付きコンテキストの境界とドメインの実装は次の図のようになります。

この図では、顧客管理は分野に関する専門知識に基づいて構築されているため、他のドメインに提供するデータが十分に把握されています。 顧客管理の内部アーキテクチャは分離されているため、これらの境界内のすべてのアプリケーション コンポーネントはアプリケーション固有のインターフェイスとデータ モデルを使用して直接通信できます。

他のドメインへのデータ配布を形式化するために、データ製品 と明確な相互運用性の標準が使用されます。 このアプローチでは、すべてのデータ製品もドメインに合わせ、ユビキタス言語を継承します。これは、そのドメインのニーズに対応するために、同じドメインの利害関係者や設計者が合意した、構築された形式化言語です。

複数の機能の実現による追加ドメイン

ビジネス機能マップを使用する場合は、一部のビジネス機能を複数回インスタンス化できることを確認することが重要です。

たとえば、Tailwind Traders では、"手荷物の取り扱いおよび遺失物" のローカライズされた実現 (または実装) を複数持つことがあります。 1 つの基幹業務が、アジアでのみ営業しているとします。 この文脈では、"手荷物の取り扱いおよび遺失物" は、アジア関連の航空機に対して実現する機能です。 別の基幹業務がヨーロッパ市場を対象にしている場合もあり、この文脈では、別の "手荷物の取り扱いおよび遺失物" 機能が使用されます。 複数のインスタンスを使用するこのシナリオでは、異なるテクノロジ サービスを使用する複数のローカライズされた実装と、それらのサービスを運用する分離したチームがもたらされる可能性があります。

ビジネス機能と機能インスタンス (実現) の関係は一対多です。 このため、余分な (サブ) ドメインが発生します。

共有機能を見つけて共有データに注意する

共有されるビジネス機能をどのように扱うかは重要です。 通常は、共有機能をサービス モデルとして一元的に実装し、これらをさまざまな基幹業務に提供します。 この種の機能の例として、"顧客管理" があります。 Tailwind Traders の例では、アジアとヨーロッパの両方の基幹業務で、クライアントに対して同じ管理が使用されています。

しかし、ドメイン データ所有権を共有機能にどのように投影できるでしょうか。 同じ共有管理内の顧客に対して複数のビジネス担当者が説明責任を持つ場合もあります。

アプリケーション ドメインとデータ ドメインがあります。 ご使用のドメインと境界付きコンテキストは、データ製品の視点から完全には一致しません。 逆に、ビジネス機能の観点から、まだ 1 つのデータの懸念があると主張できます。

複雑なベンダー パッケージ、SaaS ソリューション、レガシ システムなどの共有機能については、ドメイン データの所有権のアプローチで一貫性を保持してください。 データ製品を使用してデータの所有権を分離できますが、これにはアプリケーションの改善が必要になる場合があります。 Tailwind Traders の "顧客管理" の例では、アプリケーション ドメインからのさまざまなパイプラインによって、複数のデータ製品 (アジア関連のすべての顧客に対して 1 つのデータ製品、およびヨーロッパ関連のすべての顧客に対して 1 つ) が生成される場合があります。 このような状況では、複数のデータ ドメインが同じアプリケーション ドメインから生成されます。

また、アプリケーション ドメインに、それ自身の内部のデータの所有権を区別するためにメタデータをカプセル化する単一のデータ製品を作成するように依頼することもできます。 たとえば、所有権のために列名を予約し、各行を 1 つの特定のデータ ドメインにマッピングできます。

複数のビジネス機能を提供するモノリスを特定する

大企業や伝統的な企業でよく見られる複数のビジネス機能に対応するアプリケーションにも注意してください。 このシナリオ例において、Tailwind Traders では "コスト管理" と "アセットと資金調達" の両方を使いやすくする複雑なソフトウェア パッケージを使用します。 これらの共有アプリケーションは、可能な限り多くの機能を提供するモノリスであり、大きく複雑になります。 このような状況では、アプリケーション ドメインを大きくする必要があります。 複数のデータ ドメインが 1 つのアプリケーション ドメインに存在する共有所有権についても同じことが適用されます。

ソースに合わせたドメイン、再配信ドメイン、コンシューマーに合わせたドメインのための設計パターン

ドメイン をマップするときに、データの作成、消費、または再配信に基づいてパターンを選択できます。 アーキテクチャでは、ドメイン の特定の特性に基づいて、ドメイン をサポートするテンプレートを設計できます。

ソース システムに合わせたドメイン

ソース システムに合わせたドメインは、データを発信するソース システムに合わせて調整されます。 これらのシステムは、通常、トランザクションまたは稼働中のシステムです。

目標は、これらの貴重なソース システムからデータを直接キャプチャすることです。 提供するドメインからデータ製品を読み取り最適化し、大量のデータ消費を実現します。 データの変換と共有のための標準化されたサービスを使用して、これらのドメインを使いやすくします。

これらのサービス (事前構成済みのコンテナー構造を含む) を使用すると、ソース指向のドメイン チームがより簡単にデータを発行できます。 これは中断とコストを最小限に抑えた抵抗が最も少ない経路です。

コンシューマーに合わせたドメイン

コンシューマーに合わせたドメインは、ソースに合わせたドメインの反対です。 これらは、他のドメインからのデータを必要とする特定のエンドユーザー ユース ケースに合わせて調整されます。 顧客に合わせたドメインでは、組織の使用事例に合うようにデータが使用および変換されます。

これらの消費ニーズに対応するために、データの変換と使用のための共有データ サービスを提供することを検討してください。 たとえば、データ パイプライン、ストレージ インフラストラクチャ、ストリーミング サービス、分析処理などを扱うための、ドメインに依存しないデータ インフラストラクチャ機能を提供できます。

再配信ドメイン

データの再利用性は、別の困難なシナリオです。 たとえば、ダウンストリームのコンシューマーがさまざまなドメインのデータの組み合わせに関心を持っている場合、データを集計したり、多くのドメインで必要な高レベルのデータを組み合わせたりするデータ製品を作成できます。 これにより、繰り返しの作業を回避できます。

データ製品と分析ユース ケースの間に強い依存関係を作成しないでください。 代わりに柔軟性と疎結合を目指してください。 次のモデルは、柔軟性を実現する方法を示しています。 あるドメインで、データ製品と分析ユース ケースの両方の所有権が付与され、データ製品の作成とデータ使用のための別々のプロセスが設計されました。

重複するドメイン パターンを定義する

ドメイン モデリングは多くの場合、データまたはビジネス ロジックがドメイン間で共有されている場合に複雑になります。 大規模な組織では、ドメインは多くの場合、他のドメインからのデータに依存しています。 他のサブドメインが標準化して恩恵を受けられる方法で、統合ロジックを提供する汎用ドメインを使用すると便利なことがあります。 サブドメイン間の共有モデルを小さく維持し、常にユビキタス言語に合わせます。

重複するデータ要件に対して、ドメイン駆動設計からさまざまなパターンを使用できます。 選択できるパターンの簡単な概要を次に示します。

• 再利用性よりも関連する重複のコストを優先する場合は、別々の方法パターンを使用できます。 再利用性を犠牲にして、柔軟性と機敏性を高めます。
• 1 つのドメインが強力で、ダウンストリームのコンシューマーのデータとニーズの所有権を取得する場合は、 顧客 - サプライヤー パターンを使用できます。 欠点としては、懸念事項が競合したり、ダウンストリーム チームに成果物およびスケジュールの優先順位のネゴシエートを強制したりすることが挙げられます。
• 新しく作成されたドメイン内で統合ロジックを計画外の方法で調整する場合は、パートナーシップ パターンを使用できます。 すべてのチームが協力し、互いのニーズを考慮します。 誰も自由に共有ロジックを変更できないため、関係者全員の強い関与が必要です。
• すべてのドメインをすべての要件に準拠させるには、準拠者 (conformist) パターンを使用できます。 統合作業が複雑な場合、他の当事者が制御できない場合、またはベンダー パッケージを使用する場合は、このパターンを使用します。

いずれの場合も、ドメインが相互運用性の標準に準拠している必要があります。 他のドメイン用に新しいデータを生成するパートナーシップ ドメインでは、所有権の取得など、他のドメインと同様にデータ製品を公開する必要があります。

ドメインの責任

データ メッシュでは、データの所有権をドメイン チーム間で分散することで所有権を分散化します。 多くの組織にとって、これはガバナンスに関する一元化されたモデルから、フェデレーション モデルに移行することを意味します。 ドメイン チームには、次のようなタスクが割り当てられます。

• インジェスト、クリーニング、データ変換などのデータ パイプラインの所有権を取得して、できるだけ多くのデータ顧客のニーズに対応する
• SLA や、データ コンシューマーが設定した品質対策などへの準拠によるデータ品質の向上
• 行レベルおよび列レベルの詳細なフィルター処理のためのメタデータのカプセル化や予約列名の使用
• 以下を含むメタデータ管理標準を遵守します。
  • アプリケーションとソース システムのスキーマ登録
  • 検出可能性を向上させるためのメタデータ
  • バージョン管理情報
  • データ属性とビジネス用語のリンケージ
  • ドメイン間のより良い統合を可能にする メタデータ情報の整合性
• プロトコル、データ形式、データ型を含むデータ相互運用性標準への準拠。
• ソース システムと統合サービスをスキャナーにリンクするか、系列を手動で提供することによる系列の提供
• IAM アクセス レビューやデータ コントラクトの作成など、データ共有タスクへの準拠

切り離しのための細分性のレベル

データ ドメインを認識して使いやすくする方法がわかったら、切り離しに適したレベルのドメイン粒度とルールを設計する方法について学習できます。 アーキテクチャを分解するとき、2 つの重要な側面が関与します。

1 つの側面は、機能ドメインの細分性と境界付きコンテキストの設定です。 ドメインは特定の作業方法に従い、共有サービスを使用してすべてのドメインでデータを使用できるようにしたり、所有権を取得したり、メタデータ標準に準拠したりすることなどがあります。

データ分散のために、可能な場合はきめ細かい境界を設定します。 データドリブンにするということは、データを集中的に再利用できるようにするということです。 境界を緩くしすぎると、多くのアプリケーション間で望ましくない結合が強制され、データの再利用性が失われます。 データがビジネス機能の境界を越えるたびに切り離すよう努めます。 ドメイン内では、ドメインの内部アーキテクチャ内での密結合が許可されます。 ただし、ビジネス機能の境界を越える場合は、ドメインを切り離したままとし、他のドメインとの共有のために読み取り最適化データ製品を分散させる必要があります。

もう 1 つの重要な側面は、技術ドメインの細分性とインフラストラクチャの使用状況です。 データ ランディング ゾーンを使用すると、データ製品を作成するデータ アプリケーションにサービスを提供するための機敏性を実現できます。 共有インフラストラクチャとサービスを基礎として持つこの種のランディング ゾーンを、どのように作成すればよいでしょうか。 機能ドメインは論理的に一緒にグループ化されるため、共有プラットフォーム インフラストラクチャの候補として適しています。 これらのランディング ゾーンを作成する際に考慮すべきいくつかの要素を次に示します。

• データを操作および共有するときの凝集度と効率性は、機能ドメインをデータ ランディング ゾーンに合わせて調整する上での強力な要因です。 これは、ドメイン間で大規模なデータ製品を絶えず共有する傾向であるデータ グラビティに関連します。
• リージョンの境界により、追加のデータ ランディング ゾーンが実装される可能性があります。
• 所有権、セキュリティ、または法的な境界により、ドメインの分離が強制される可能性もあります。 たとえば、一部のデータを他のドメインに表示することはできません。
• 柔軟性と変化のペースは重要な要因です。 一部のドメインではイノベーションの速度が速くなる可能性がある一方、他のドメインでは安定性を強く重視します。
• 機能の境界によって、チームが引き離される可能性があります。 その例として、ソース指向とコンシューマー指向の境界があります。 ドメイン チームの半分の人は、他のものよりも特定のサービスを評価する可能性があります。
• 機能を売却または分離する可能性がある場合は、他のドメインの共有サービスとの緊密な統合を避ける必要があります。
• チームの規模、スキル、成熟度はすべて重要な要因です。 高度なスキルを持つ成熟したチームは、たいてい独自のサービスとインフラストラクチャを運用することを好みますが、成熟度の低いチームはプラットフォーム メンテナンスの追加のオーバーヘッドをあまり高く評価しません。

多くのデータ ランディング ゾーンをプロビジョニングする前に、ドメインの分解を確認し、基礎となるインフラストラクチャを共有するための候補となる機能ドメインを見極めてください。

まとめ

ビジネス機能モデリングは、データ メッシュ アーキテクチャでドメインをより適切に認識して整理するのに役立ちます。 これにより、データとアプリケーションによってビジネスに提供される価値の全体像が得られるのと同時に、データ戦略とビジネス ニーズに優先順位を付け、重点を置くのに役立ちます。 ビジネス機能モデリングは、データ以外に対しても使用できます。 たとえば、スケーラビリティが懸念される場合は、このモデルを使用して、最も重要なコア機能を特定し、それらに対する戦略を策定できます。

一部の専門家は、すべてを事前にマッピングしてターゲット状態アーキテクチャを構築することは負荷の大きい仕事であるという懸念を提起しています。 そうする代わりに、新しいデータ メッシュ アーキテクチャにドメインをオンボードするときに、ドメインを有機的に識別することを推奨しています。 ターゲットの状態をトップダウンで定義する代わりに、ボトムアップで作業し、現在の状態を探索して実験し、ターゲット状態に移行するというやり方です。 この提案されたアプローチの方が速いかもしれませんが、大きなリスクを伴います。 物事が壊れ始めると、手間のかかる移転や再モデル化の作業の真っただ中に容易に陥ってしまう可能性があります。 トップダウンとボトムアップの両方向から作業し、時間をかけて中間点で合流させるのが、巧妙なアプローチです。

次のステップ

• データ製品とは