データ メッシュは基本的に、分散化とドメインへの責任の分散に基づいています。 ビジネスの一部を本当に理解している場合は、関連するデータを管理し、その精度を確保することをお勧めしています。 これは、ドメイン指向のデータ所有権の原則です。
ドメイン指向のデータ所有権を昇格するには、まずデータ アーキテクチャを分解する必要があります。 データ メッシュの創設者 Zhamak Dehghani は、データ ドメインの識別に役立つ便利な方法として、ソフトウェア開発に対する Domain-Driven Design (DDD) アプローチを推進しています。
データ管理に DDD を使用する場合の難しさは、DDD の元のユース ケースが、ソフトウェア開発コンテキストで複雑なシステムをモデル化していたということです。 もともとはエンタープライズ データをモデル化するために作成されたのではなく、データ管理の実践者にとって、その方法は抽象的で技術的な場合があります。 多くの場合、DDD の理解が不足しています。 実践者は、その概念の概念を把握するのが難しすぎる、またはソフトウェア アーキテクチャやオブジェクト指向プログラミングからデータランドスケープに例を投影しようとするのが難しいと感じます。 この記事では、DDD を理解して使用できるように、実用的なガイダンスと明確なボキャブラリを提供します。
ドメイン駆動型設計
Eric Evans によって導入された Domain-Driven Design は、大規模な組織の複雑なシステムを記述するのに役立つソフトウェア開発をサポートする方法です。 DDD は、高度なプラクティスの多くがマイクロサービスなどの最新のソフトウェアおよびアプリケーション開発アプローチに影響を与えるため、一般的です。
DDD は、境界付きコンテキスト、ドメイン、サブドメインを区別します。 ドメインは、対処する問題のあるスペースです。 知識、行動、法律、活動が集まる分野です。 ドメインでのセマンティック結合、コンポーネントまたはサービス間の動作の依存関係が表示されます。 ドメインのもう 1 つの側面は、通信です。 チーム メンバーは、全員が効率的に作業できるように、チーム全体が共有する言語を使用する必要があります。 この共有言語は、ユビキタス言語 または ドメイン言語と呼ばれます。
ドメインは、複雑さを管理しやすくするためにサブドメインに分解されます。 この一般的な例は、AI/MLのデータ メッシュの運用化に関する
すべてのサブドメインが同じであるわけではありません。 たとえば、ドメインをコア、汎用、またはサポートとして分類できます。 コア サブドメインが最も重要です。 彼らは、組織をユニークにする秘密のソース、成分です。 汎用サブドメインは非特異的であり、通常は既製の製品で簡単に解決できます。 サブドメインのサポートは競争上の優位性を提供しませんが、組織を実行し続けるために必要であり、複雑ではありません。
境界付きコンテキストは、論理 (コンテキスト) 境界です。 システムとアプリケーションの設計というソリューション空間に焦点を当てています。 これは、ソリューション空間へのフォーカスの配置が理にかなっている領域です。 DDD 内には、コード、データベース デザインなどを含めることができます。 ドメインと境界付けられたコンテキストの間には、アラインメントが存在する可能性がありますが、2 つをバインドするハード ルールはありません。 有界コンテキストは本質的に技術的であり、複数のドメインとサブドメインにまたがる可能性があります。
ドメイン モデリングに関する推奨事項
データの民主化の概念としてデータ メッシュを採用し、柔軟性を高めるためにドメイン指向のデータ所有権の原則を実装する場合、これは実際にどのように機能しますか? エンタープライズ データ モデリングからドメイン駆動型設計モデリングへの移行はどのようなものでしょうか。 データ管理のために DDD からどのような教訓を得ることができますか?
問題のある領域の機能的なビジネス分解を行う
チームがデータをエンド ツー エンドで操作できるようにする前に、スコープを確認し、対処しようとしている問題領域を理解します。 技術的な実装の詳細に進む前に、まずこの演習を実行することが重要です。 これらの問題スペースの間に論理的な境界を設定すると、責任がより明確になり、より適切に管理できるようになります。
問題のスペースをグループ化するときに、ビジネス アーキテクチャを確認します。 ビジネス アーキテクチャ内には、特定の目的や成果を達成するために企業が所有する能力や能力、または交換するビジネス機能があります。 この抽象化は、組織の戦略的なビジネス目標と目標に合わせて、データ、プロセス、組織、テクノロジを特定のコンテキストにパックします。 ビジネス機能マップには、ミッションとビジョンを満たすために必要と思われる機能領域が表示されます。
次のモデルでは、架空の会社 Tailwind Traders の機能分解を表示できます。
Tailwind Traders は、ビジネス機能マップに一覧表示されているすべての機能領域をマスターして成功させる必要があります。 Tailwind Traders は、たとえば、オンラインチケットまたはオフラインチケット管理システムの一部としてチケットを販売したり、パイロット管理プログラムの一部として飛行機を飛ばすことができるパイロットを持っている必要があります。 一部の活動を外部委託し、他の活動を中核として維持することができます。
実際に観察するのは、ほとんどのユーザーがビジネス機能を中心に編成されていることです。 同じビジネス機能に取り組んでいるユーザーは、同じボキャブラリを共有します。 同じことが、アプリケーションとプロセスにも当てはまります。通常は、サポートされるアクティビティのまとまりに基づいて、適切に調整され、緊密に接続されます。
ビジネス機能マッピングは優れた出発点ですが、ここではストーリーは終わりません。
ビジネス機能をアプリケーションとデータにマップする
エンタープライズ アーキテクチャをより適切に管理するには、ビジネス機能、境界付きコンテキスト、アプリケーションを調整します。 それをする際は、いくつかの基本ルールに従うことが重要です。
ビジネス機能は、ビジネス レベルを維持し、抽象的なままである必要があります。 これらは、組織が実行する内容を表し、問題のスペースを対象とします。 ビジネス機能を実装すると、特定のコンテキストの実現 (機能インスタンス) が作成されます。 ソリューション空間内のこのような境界内で複数のアプリケーションとコンポーネントが連携して、特定のビジネス価値を実現します。
特定のビジネス機能に合わせたアプリケーションとコンポーネントは、さまざまなビジネス上の懸念に対処するため、他のビジネス機能と一致するアプリケーションから切り離された状態を維持します。 境界付きコンテキストは、ビジネス機能から派生し、排他的にマップされます。 これらはビジネス機能の実装の境界を表し、ドメインのように動作します。
ビジネス機能が変更されると、境界付きコンテキストが変更されます。 ドメインと対応する境界付けられたコンテキスト間の完全な連携が望ましいですが、後のセクションで学習するように、現実が理想的とは異なる場合があります。
Tailwind Traders への機能マッピングを投影する場合、境界付きコンテキスト境界とドメイン実装は次の図のようになります。
この図では、顧客管理は主題の専門知識に基づいて構築されているため、他のドメインに提供するデータを最もよく把握しています。 Customer Management の内部アーキテクチャは分離されているため、これらの境界内のすべてのアプリケーション コンポーネントは、アプリケーション固有のインターフェイスとデータ モデルを使用して直接通信できます。
データ製品の と明確な相互運用性の標準は、他のドメインへのデータ分散を形式化するために使用されます。 このアプローチでは、すべてのデータ製品もドメインと一致し、ユビキタス言語を継承します。これは、同じドメインの利害関係者やデザイナーが合意した、構築された形式化された言語であり、そのドメインのニーズに対応します。
複数の機能の実現による追加ドメイン
ビジネス機能マップを使用する場合は、一部のビジネス機能を複数回インスタンス化できることを確認することが重要です。
たとえば、Tailwind Traders は、"手荷物の取り扱いや紛失品" を複数のローカライズされた実現 (または実装) している可能性があります。ビジネスの 1 つの行がアジアでのみ動作するとします。 この文脈では、「手荷物の取り扱いおよび紛失品」はアジア関連の飛行機に特化されたサービスです。 別の基幹業務が欧州市場をターゲットにしている可能性があり、このコンテキストでは、別の "手荷物の取り扱いや紛失品" 機能が使用されます。 この複数のインスタンスのシナリオでは、異なるテクノロジ サービスを使用して複数のローカライズされた実装を行い、それらのサービスを運用するチームが分離する可能性があります。
ビジネス機能と機能インスタンス (実現) の関係は一対多です。 このため、最終的に追加の (サブ) ドメインが作成されます。
共有機能を見つけて共有データに注意する
共有ビジネス機能の処理方法は重要です。 通常は、共有機能をサービス モデルとして一元的に実装し、異なる基幹業務に提供します。 "顧客管理" は、この種の機能の例です。 Tailwind Traders の例では、アジアとヨーロッパの両方のビジネス ラインがクライアントに同じ管理を使用しています。
しかし、共有機能にドメイン データの所有権を投影するにはどうすればよいですか? 複数のビジネス担当者が、同じ共有管理内の顧客に対して説明責任を持つ可能性があります。
アプリケーション ドメインとデータ ドメインがあります。 ドメインと境界付けられたコンテキストは、データ製品の観点から完全には一致しません。 逆に、ビジネス機能の観点からは、データに関する懸念がまだ 1 つあると主張できます。
複雑なベンダー パッケージ、SaaS ソリューション、レガシ システムなどの共有機能の場合は、ドメイン データの所有権のアプローチで一貫している必要があります。 データ製品を使用してデータの所有権を分離できます。この場合、アプリケーションの改善が必要になる場合があります。 Tailwind Traders の "Customer Management" の例では、アプリケーション ドメインとは異なるパイプラインによって、複数のデータ製品 (アジア関連のすべての顧客に対して 1 つ、ヨーロッパ関連のすべての顧客に対して 1 つ) が生成される場合があります。 この状況では、複数のデータ ドメインが同じアプリケーション ドメインから生成されます。
また、アプリケーション ドメインに対して、データの所有権を識別するためのメタデータをカプセル化する単一のデータ製品を作成するように依頼することもできます。 たとえば、所有権のために列名を予約し、各行を 1 つの特定のデータ ドメインにマッピングすることができます。
複数のビジネス機能を提供するモノリスを特定する
また、大企業や従来の企業でよく見られる複数のビジネス機能に対応するアプリケーションにも注意してください。 このシナリオの例では、Tailwind Traders は複雑なソフトウェア パッケージを使用して、"コスト管理" と "資産と資金調達" の両方を容易にします。これらの共有アプリケーションは、可能な限り多くの機能を提供するモノリスであり、大きく複雑になります。 このような状況では、アプリケーション ドメインを大きくする必要があります。 同じことが、複数のデータ ドメインがアプリケーション ドメインに存在する共有所有権にも適用されます。
ソースアラインド、再配信、およびコンシューマーアラインド ドメインの設計パターン
ドメインをマップするときに、データの作成、消費、または再配信に基づいてパターンを選択できます。 アーキテクチャでは、ドメイン固有の特性に基づいてドメインをサポートするテンプレートを設計できます。
ソース システムに合わせたドメイン
ソース システムにアラインされたドメインは、データが生成されるソース システムと一致します。 通常、これらのシステムはトランザクションまたは運用可能です。
目標は、これらのゴールデン ソース システムから直接データをキャプチャすることです。 提供するドメインからの読み取り最適化されたデータ製品により、大量のデータ消費を実現します。 データ変換と共有のために標準化されたサービスを使用して、これらのドメインを容易にします。
構成済みのコンテナー構造を含むこれらのサービスを使用すると、ソース指向のドメイン チームがより簡単にデータを発行できます。 これは、中断とコストを最小限に抑えた最小抵抗のパスです。
コンシューマーアラインド ドメイン
コンシューマーアラインド ドメインは、ソースアラインド ドメインとは逆です。 これらは、他のドメインからのデータを必要とする特定のエンドユーザーのユース ケースに合わせて調整されています。 顧客が連携するドメインは、組織のユース ケースに合わせてデータを使用および変換します。
これらの消費ニーズに対応するために、データ変換と使用のために共有データ サービスを提供することを検討してください。 たとえば、データ パイプライン、ストレージ インフラストラクチャ、ストリーミング サービス、分析処理などを処理する、ドメインに依存しないデータ インフラストラクチャ機能を提供できます。
再配信ドメイン
データの再利用性は、異なる、より困難なシナリオです。 たとえば、ダウンストリーム コンシューマーが異なるドメインのデータの組み合わせに関心がある場合は、データを集計するデータ製品を作成したり、多くのドメインで必要な高レベルのデータを組み合わせたりすることができます。 これにより、繰り返し作業を回避できます。
データ製品と分析ユース ケースの間に強力な依存関係を作成しないでください。 代わりに柔軟性と疎結合を目指してください。 次のモデルは、柔軟性を実現する方法を示しています。 ドメインは、データ製品と分析ユース ケースの両方の所有権を取得し、データ製品の作成とデータ使用のための個別のプロセスを設計しています。
重複するドメイン パターンを定義する
ドメイン モデリングは、多くの場合、データまたはビジネス ロジックがドメイン間で共有されている場合に複雑になります。 大規模な組織では、多くの場合、ドメインは他のドメインからのデータに依存します。 統合ロジックを提供する汎用ドメインを、他のサブドメインが標準化してメリットを得られる方法で用意すると便利です。 サブドメイン間の共有モデルを小さくし、常にユビキタス言語に合わせます。
重複するデータ要件では、ドメイン駆動型設計とは異なるパターンを使用できます。 選択できるパターンの簡単な概要を次に示します。
- 再利用性よりも関連する重複のコストを優先する場合は、別々の方法パターンを使用できます。 再利用性が犠牲になり、柔軟性と機敏性が向上します。
- 1 つのドメインの力が強く、ダウンストリーム コンシューマーのデータとニーズの所有権を持ちたがっている場合は、顧客サプライヤーの パターンを使用できます。 欠点としては、競合する懸念事項や、ダウンストリーム チームに成果物とスケジュールの優先順位の交渉を強制することが挙げられます。
- パートナーシップ パターンは、新しく作成されたドメイン内で計画外の方法で統合ロジックを調整する場合に使用できます。 すべてのチームが協力し、お互いのニーズを考慮します。 誰も共有ロジックを自由に変更できないため、関係するすべてのユーザーから大きなコミットメントが必要です。
- 準拠 パターンを使用して、すべてのドメインをすべての要件に準拠させることができます。 このパターンは、統合作業が複雑な場合、他の関係者が制御できない場合、またはベンダー パッケージを使用する場合に使用します。
いずれの場合も、ドメインは相互運用性標準に従う必要があります。 他のドメインの新しいデータを生成するパートナーシップ ドメインでは、所有権の取得など、他のドメインと同様にデータ製品を公開する必要があります。
ドメインの責任
データ メッシュは、ドメイン チーム間で分散することで、データの所有権を分散化します。 多くの組織にとって、これは、ガバナンスに関する集中型モデルからフェデレーション モデルへの移行を意味します。 ドメイン チームには、次のようなタスクが割り当てられます。
- インジェスト、クリーニング、データ変換などのデータ パイプラインの所有権を取得して、できるだけ多くのデータ顧客のニーズに対応する
- データ品質の向上 (SLA への準拠や、データ コンシューマーによって設定された品質メジャーを含む)
- 詳細な行レベルと列レベルのフィルター処理のためのメタデータのカプセル化または予約列名の使用
- 次のようなメタデータ管理標準に準拠しています。
- アプリケーションとソース システムのスキーマの登録
- 検出可能性を向上するためのメタデータ
- バージョン管理情報
- データ属性とビジネス用語のリンケージ
- メタデータ 情報の整合性により、ドメイン間の統合が向上します
- プロトコル、データ形式、データ型を含むデータ相互運用性標準への準拠
- ソース システムと統合サービスをスキャナーにリンクするか、系列を手動で提供することによる系列の提供
- IAM アクセス レビューやデータ コントラクトの作成など、データ共有タスクへの準拠
分離の粒度レベル
データ ドメインを認識して容易にする方法を理解したら、分離に適したレベルのドメイン細分性とルールを設計する方法を学習できます。 アーキテクチャを分解すると、2 つの重要なディメンションが発生します。
機能ドメインの粒度と境界付きコンテキストの設定は 1 つのディメンションです。 ドメインは特定の作業方法に準拠し、共有サービスを使用してすべてのドメインでデータを使用できるようにする、所有権を取得する、メタデータ標準に準拠する、などです。
データ分散に可能な限り、細かい境界を設定します。 データドリブンになるのは、データを集中的に再利用できるようにすることです。 境界を緩めすぎると、多くのアプリケーション間で望ましくない結合が強制され、データの再利用性が失われます。 データがビジネス機能の境界を越えたたびに分離するよう努めます。 ドメイン内では、ドメインの内部アーキテクチャ内で厳密な結合が許可されます。 ただし、ビジネス機能の境界を越える場合、ドメインは分離された状態を維持し、他のドメインと共有するために読み取り最適化されたデータ製品を配布する必要があります。
技術ドメインとインフラストラクチャ使用率の粒度は、もう 1 つの重要なディメンションです。 データ ランディング ゾーン、データ製品を作成する データ アプリケーションにサービスを提供する機敏性を実現できます。 共有インフラストラクチャとサービスを使用して、この種のランディング ゾーンを作成するにはどうすればよいですか? 機能ドメインは論理的にグループ化され、プラットフォーム インフラストラクチャの共有に適しています。 これらのランディング ゾーンを作成する際に考慮すべきいくつかの要因を次に示します。
- データの操作と共有時の凝集と効率性は、機能ドメインをデータ ランディング ゾーンに合わせる強力な原動力です。 これは、ドメイン間で大きなデータ製品を絶えず共有する傾向であるデータの重力に関連しています。
- リージョンの境界により、追加のデータ ランディング ゾーンが実装される可能性があります。
- 所有権、セキュリティ、または法的境界により、ドメインの分離が強制される可能性があります。 たとえば、一部のデータは他のどのドメインにも表示できません。
- 柔軟性と変化のペースは重要な要因です。 一部のドメインではイノベーションの速度が速くなる一方で、他のドメインは安定性を強く重視します。
- 機能境界により、チームを引き離すことができます。 その例として、ソース指向とコンシューマー指向の境界があります。 ドメイン チームの半分は、他のユーザーよりも特定のサービスを評価する可能性があります。
- 機能を販売または分離する可能性がある場合は、他のドメインの共有サービスと緊密に統合しないようにする必要があります。
- チームの規模、スキル、成熟度はすべて重要な要素です。 高度なスキルと成熟したチームは、多くの場合、独自のサービスとインフラストラクチャを運用することを好みますが、成熟度の低いチームはプラットフォームメンテナンスの余分なオーバーヘッドを評価する可能性は低くなります。
多数のデータ ランディング ゾーンをプロビジョニングする前に、ドメインの分解を確認し、基になるインフラストラクチャを共有するための候補となる機能ドメインを特定します。
概要
ビジネス機能モデリングは、データ メッシュ アーキテクチャ内のドメインをより適切に認識して整理するのに役立ちます。 データとアプリケーションがビジネスに価値を提供する方法の全体像を提供すると同時に、データ戦略とビジネス ニーズに優先順位を付け、集中することができます。 データだけでなく、ビジネス機能モデリングを使用することもできます。 たとえば、スケーラビリティが懸念される場合は、このモデルを使用して最も重要なコア機能を特定し、それらの戦略を策定できます。
一部の実務家は、すべてを事前にマッピングしてターゲット状態アーキテクチャを構築することは集中的な演習であるという懸念を高めます。 代わりに、新しいデータ メッシュ アーキテクチャにドメインをオンボードするときに、ドメインを有機的に識別することをお勧めします。 ターゲット状態を上から下に定義するのではなく、ボトムアップのアプローチで現在の状態を調査し、実験しながらターゲット状態へと移行します。 この提案されたアプローチはより速くなるかもしれませんが、重大なリスクを伴います。 物事が壊れ始めると、複雑な引っ越しや改装の作業の真っ最中であることが簡単に起こりえます。 トップダウンとボトムアップの両方の方向から作業し、時間の経過と共に途中で会議を行う方が、より微妙なアプローチです。