ここでは、DOAの考え方を適用して構築するDOA型データ基盤と、DDDの考え方を適用して構築するDDD型データ基盤について次の順で解説します。
DOA型データ基盤と、DDD型データ基盤のイメージ図は次のようになります。
集中型と分散型
ネットワークの形態は、大きく、集中型と分散型に分けることができます。
集中型は、ネットワークを構成する、あるノードを中心に他のノードが繋がっている形態で、分散型は、すべてのノードが相互に連携している形態です。
集中型の場合、中心となるノードに機能や負荷が集中するので、中心となるノードが単一障害点となり、それが機能しなくなるとネットワーク全体が機能しなくなる可能性が高くなりますが、中心となるノードだけを集中管理すればよいので管理コストやネットワークコスト（ネットワークの消費量）は比較的低くなります。
次に、分散型の場合、中心となるノードがなく、すべてのノードが相互に連携しているので機能や負荷が分散し、あるノードが機能しなくなるとネットワーク全体が機能しなくなる可能性は低いですが、すべてのノードと、それらの接続を管理する必要があるので管理コストやネットワークコストは比較的高くなります。
今回のテーマとして扱う、DOA型データ基盤は集中型になり、DDD型データ基盤は分散型になります。
なので、それぞれが、集中型、分散型のメリットとデメリットを継承します。
DOA型データ基盤
まず、DOA型データ基盤から見ていきましょう。
データ中心アプローチ（DOA）とは
記事開発手法の変遷とドメイン駆動設計×マイクロサービスでも説明したように、データ中心アプローチ（DOA）は、処理からデータを完全に分離し、データを構造化するとともに全体で一元管理する手法です。
DOAのメリットは、データが構造化され全体で一元管理されるので、データの不整合が起こりにくいことです。
DOA型データ基盤とは
このデータを構造化して全体で一元管理するという思想に基づいて構築されるデータ基盤がDOA型データ基盤です。
記録システム（SoR）である基幹系システムのデータを一旦、中央のデータレイクに取り込み、そのデータに対してクレンジングも含めたETL（抽出・変換・読込）処理を行い中央のデータウェアハウス（データ倉庫）に格納します。
中央のデータウェアハウスのデータは、目的別のデータマートに分割されてデータ分析で利用されます。
それから、データレイクの非構造化データも含めてデータをベクトル化し、ナレッジベースを構築することで生成AIに利用しやすい形に変換します。
データを分析することによって得られる顧客やパートナー、従業員の隠れたニーズや深層心理、つまりインサイトを理解するためのシステムをSoI（System of Insight）といいますが、ここでは、SoIを、BI（ビジネスインテリジェンス）ツールを通して人が洞察を得るBI系SoIと、AIが洞察を得るAI系SoIに分けています。
DOA型データ基盤のメリット
さて、DOA型データ基盤のメリットの一つは、データが構造化され全体で一元管理されるので、データの不整合が起こりにくいことです。
また、DOA型データ基盤には、それが集中型なので、データ基盤を構築し管理するコストが比較的低いというもう一つのメリットがあります。
現在、多くの会社では、DOA型のデータ基盤を構築しているのではないでしょうか。
その背景には、これまでツギハギして改修してきた基幹システムのデータの品質が低下してダーティになっているという事実があります。
大本（おおもと）のデータがダーティでも、中央でクレンジングして利用すれば問題ないという裏事情が潜んでいるのです。
DOA型データ基盤のデメリット
それでは、DOA型データ基盤のデメリットは何でしょうか。
それは、データが中央で一元管理されているので、中央のデータ構造の変更による利用者に対する影響が大きい、結果的に、企業の業務とシステムを変化に弱い脆弱な構造にしてしまうということです。
これは、DOA型データ基盤が集中型である故に、どうしても免れないリスクになります。
先行き不透明で予測困難な昨今、変化に柔軟に対応できないシステムはビジネスの足かせになり、企業の競争優位性を阻害する恐れがあります。
DDD型データ基盤
ドメイン駆動設計（DDD）とは
ドメイン駆動設計（DDD）とは、ドメイン（開発対象となる業務領域）を中心に据えて、システムを設計・開発する手法です。
この手法により、業務の本質を表すドメインの構造や振る舞い（業務ルールや機能）を正確にモデル化できます。
また、DDDは、ドメインの機能やデータをオブジェクトとしてモジュール化し、オブジェクト同士のメッセージングによってシステムを構成するため、再利用性や拡張性が高く、変化に強い堅牢なシステムを構築することができます。
DDDの重要なポイントは、技術的な設計よりも、まず組織全体で適切な業務領域（ドメイン）をどのように定義し設計するかにあります。
すなわち、ドメイン駆動設計の本質は、究極的には業務の仕組みそのもの、すなわちビジネスアーキテクチャの設計にあるといえます。
一方で、システムを構成する要素を、独立してデプロイ可能な小さなソフトウェア部品に分割し、それぞれが実現するサービスを他の部品に提供し合うことで全体のシステムを構成するという考え方が、マイクロサービスです。
一つのマイクロサービスは、そのサービスを実現するために必要なデータベースも内包します。
したがって、マイクロサービスはデータベースを含めて処理とデータをカプセル化した自律したソフトウェア部品となります。
このように、ドメイン駆動設計によって設計されたドメインごとにマイクロサービスを構築し、それらを疎結合で連携させることで、ビジネスとITが一体となり、環境の変化に柔軟に適応できる「変化に強いシステム」を実現することができます。
DDD型データ基盤とは
ドメイン駆動設計によって設計された業務ドメインごとにマイクロサービスを構築し、そこにデータをカプセル化することで構築するデータ基盤がDDD型データ基盤です。
さて、DOA型データ基盤の場合、通常、ファイル転送によって一括でSoRのデータを中央で管理されるデータストアに格納します。
一方、DDD型データ基盤の場合、SoRのデータが更新される都度、非同期メッセージングによってSoRののデータがサブジェクト別データマートに送信され、更新系データと参照系データの同期を取ります。
このデータ連携モデルは、コマンドクエリ分離パターンというアーキテクチャパターンで、DDD型データ基盤の大きな特徴です。
DDD型データ基盤のメリット
DDD型データ基盤の最大のメリットは、
- DDDによって業務の仕組にしたがって業務ドメインが設計されていること
- 業務ドメインごとにマイクロサービスを構築し、そこに機能とデータがカプセル化されており、それらが疎結合することでシステム全体を構成すること
によって、ビジネスとシステムが連動し、企業の業務とシステム変化に強い堅牢な構造にすることができることです。
DDD型データ基盤のデメリット
一方、DDD型データ基盤のデメリットは、分散型であるが故にコストが高いことです。
個々のマイクロサービスの更新系データが更新される都度、サブジェクト別データマートの参照系データが更新されるというCQRSアーキテクチャは、定期的に一括で更新されるファイル転送に比べて、ネットワークコストが高くつきます。
しかし、１日に１回、１時間に１回という一括ファイル転送の場合、一括で転送するデータの範囲の問題や、データ連携の遅延の問題が発生します。
ソースシステムでデータが生成されてからターゲットシステムでデータが利用可能になるまでの時間差のことをレイテンシといいます。
データの品質を測る指標の一つのデータの適時性があり、レイテンシをどの程度許容できるか、つまり遅延許容度で測ることができます。
データの適時性が重視されない場合は、定期的な一括ファイル転送で問題ないですが、適時性が求められる業務の場合、定期的な一括ファイル転送がシステム全体のボトルネックになる可能性があります。
その点、非同期メッセージングは、非同期なので完全リアルタイムではないですがレイテンシが低く、遅延による問題はほぼ発生しません。
それから、連携方式の技術的難易度ですが、ファイル転送は多くの企業が採用しており、比較的技術的難易度も低いと思います。
一方、非同期メッセージングの場合、ファイル転送に比べると比較的新しい技術なので採用のハードルが高いと感じられます。
しかし、実際は、JMSのようなJavaのフレームワークなど各種フレームワークが充実しており、ファイル転送と同程度、あるいは、それ以下のコストで実現することができます。
以上のように、DDD型データ基盤の場合、ネットワークコストが高くなりますが、構築コストも高くなります。
DDD型データ基盤を構築する場合、SoRを業務ドメインごとに分けて、マイクロサービス化します。
その際、各マイクロサービスで管理するデータの品質やセキュリティを担保できるように再設計します。
つまり、それまで、ツギハギだらけで汚くなっってきた機能とデータを、もう一度、クリーンアップするわけです。
なので、既存のSoRを活かすDOA型データ基盤に比べて、SoRの再構築分、コストがかかります。
DDD型データ基盤の構築方法
以上のように、既に基幹システムを構築している企業にとって、DDD型データ基盤を構築するためには、基幹システムを見直すためのコストがかかります。
しかし、
- これから基幹システムを構築する企業
- 基幹システムを再構築してモダナイズしようと考えている企業
の場合、DDD型データ基盤を構築する機会になります。
経済産業省のDX推進システムガイドラインには、レガシー刷新後のシステムについて次のように言及しています。
《レガシー刷新後のシステム：変化への追従力》
レガシー刷新後のシステムには、新たなデジタル技術が導入され、ビジネス・モデルの変化に迅速に追従できるようになっているか。
（失敗ケース）刷新後のシステムは継続してスピーディーに機能追加できるものとするとの明確な目的設定をせずに、レガシー刷新自体が自己目的化すると、DXにつながらないシステムになってしまう（再レガシー化）
（先行事例）ビジネス上頻繁に更新することが求められるものについては、マイクロサービス化によって細分化しながらアジャイル開発により刷新していくアプローチもある。これにより、リスクが軽減される可能性もある。
これから基幹システムを構築する企業がDDD型データ基盤を構築する場合、記事開発手法の変遷とドメイン駆動設計×マイクロサービスを参考にしてください。
また、基幹システムを再構築してモダナイズしようと考えている企業の場合、基幹システムを一度にマイクロサービス化するのではなく、段階的にマイクロサービス化する方法としてストラングラーアプリケーションパターンがあるので参考にしてください。
最後に、基幹システムを物理的に置き換えるのは厳しいと考える企業には、仮想MS化をお勧めします。
これは、論理的に業務ドメインで機能とデータを分割して、それぞれ、最適なAPIを設計、構築するという方法です。
DDD型データ基盤の将来
DDD型データ基盤は、業務ドメインごとにマイクロサービスを構築し、それらが疎結合することでシステム全体を構成します。
そうすると、将来、各マイクロサービスにAIエージェントを組み込むことで、それらが自律的に会話しながら、環境の変化を察知し、自動的にシステム全体を最適な状態に保つ、ホメオスタシス（恒常性）を持つシステムにすることができます。
具体的には、DDDのアダプタの部分をMCP（Model Context Protocol）対応させて、それぞれのAIエージェントを組み込むようににします。
※MCP（Model Context Protocol）とは、AIエージェントが各マイクロサービスの文脈を理解し、相互に連携するための通信プロトコルです。
例えば、次のような例を考えることができます。
- 販売管理サービスのエージェントが「売上低下」を検知
- 購買管理サービスのエージェントに「仕入見直し」提案イベントを送る
- これを基に購買サービス側で調整が行われ、全体最適を達成
このように、DDD型データ基盤は、各マイクロサービスで信頼できる機能とデータが管理されているため、AIドリブンのアーキテクチャにスムーズに移行することができます。
さて、上述したように、DOA型データ基盤は、既存の基幹システムのデータを中央に集めてつくるため、比較的低コストで構築することができます。
しかし、その背後には、これまでツギハギして改修してきた基幹システム（SoR)のデータがダーティでも、中央でクレンジングして利用すれば問題ないという考え方があります。
記録システム（SoR)である基幹システムのデータは、業務で発生した事実（データ）の源泉です。
その大元のデータの品質が悪いという問題を横においたまま、とりあえずデータ基盤を構築するという場当たり的な対応は、データ品質に関する潜在的リスクの解消にはつながらず、むしろ将来的に業務の信頼性や意思決定の正確性を損なう危険性すら孕（はら）んでいます。
したがって、データ基盤の構築と並行して、SoR自体のデータ品質向上（例：入力ルールの見直し、業務プロセスの整備、マスタ整合性の確保）に継続的に取り組むことが不可欠です。
このような状況を踏まえると、DOA型データ基盤をすでに構築している企業であっても、業務とデータの構造を一致させ、SoRの段階から高品質なデータを生成できるよう設計されたDDD（ドメイン駆動設計）型データ基盤へと再構築することは、将来にわたるデータ活用の信頼性と柔軟性を高めるうえで、十分に合理的な判断といえるでしょう。
