Table of Contents
  • データエンティティ、プロセスモデル、ビジネス要件を伝達するための共通のモデルを作成することで、チーム間のコラボレーションを向上します。
  • ソフトウェアやビジネスの問題を解決するためのパターンや原則が改善されます。
  • ソフトウェアのコードがビジネスドメインのニーズとマッチするため、開発チームとドメインエキスパートの間に誤解が生じにくくなります。

DDD（Domain-Driven Design：ドメイン駆動設計）について、皆さんはどの程度ご存知でしょうか。DDDとは、ソフトウェア開発における設計手法の一つで、ソフトウェアコードの言語や構造をビジネスドメインに合わせるというものです。このコンセプトは、2003年にEric Evans氏が発表した書籍に由来しています。ソフトウェアアーキテクト、インフォメーションアーキテクト、データエンジニア、コンピュータサイエンスの専門家がコードを整理し、深刻なストレスを伴うソフトウェア問題を解決する際に影響を与えています。 

ドメイン駆動設計は、ビジネスロジックに素晴らしい効果をもたらす、素晴らしいコンセプトです。しかし、これにETL（Extract, Transform, Load）を加えるとどうなるでしょうか？

ドメイン駆動型プロジェクトをサポートする強力なETLツールをお探しですか？Integrate.ioにはソリューションがあります。このコード不要のポイント＆クリックプラットフォームはETLを合理化し、企業を成長させ、意思決定を改善するデータセットに集中することができます。詳しくはこちらをご覧ください。

  1. ドメイン駆動設計とは？
  2. DDDコンテキストにおけるETL
  3. Integrate.ioによるデータ変換がDDDに与える影響
  4. まとめ

ドメイン駆動設計とは？

DDDは、マイクロサービスアーキテクチャーのスタイルに回帰します。マイクロサービスアーキテクチャーとは、アプリケーションを独立して展開可能で疎結合なサービスの集まりとして構成するもので、アプリケーションを単一のユニットとして構成する従来のモノリシックアーキテクチャーのスタイルとは異なります。DDDは、ブレーキ、ホイール、タイヤなどの独立したコンポーネントで構成された車のようなものだと考えてください。DDDも同様ですが、そのコンポーネントはエンティティやバリューオブジェクトなどのドメインオブジェクトです。

DDDの目的はいったい何でしょうか？問題領域（チームが問題を解決するために調べる必要のある情報）から抽象的なモデルを作成し、様々な技術をサポートすることです。この方法論は、ドメインロジックとコアドメインを中心としており、ドメインモデルに基づいた複雑な設計を容易に行うことができます。ドキュメントはあまり重視されず、チームの集合的な学習経験が重視されます。

 

DDDには多くの利点があります。

では、DDDはデータに対してはどのように適用されるのでしょうか。

DDDは、アプリケーションを単一のユニットではなく、クラスターとして捉えているため、このコンセプトの支持者は、従来のモノリシックなアーキテクチャを分散化し、データの所在と所有権を再考することを推奨しています。ドメインから集約されたデータレイクやデータウェアハウス（SnowflakeやMicrosoft Azure SQLなど）にデータを移すのではなく、各ドメインが独自のデータセットを提供し、ホストする必要があります。

ソフトウェアコンサルティング会社ThoughtWorksのプリンシパル・テクノロジー・コンサルタントであるZhamak Dehghaniは次のように述べています。「メディアプレーヤーからデータが流れてきて、ある種の集中管理された場所に送られ、集中管理されたチームがそれを受け取るのではなく、プレーヤーのドメインが自分たちのデータセットを所有、提供して、どのチームも下流の目的でアクセスできるようにしてはどうでしょうか。」Zhamak Dehghaniは、ドメイン間で「プッシュ＆インジェスト」から「サービング＆プルモデル」へと考え方を変えることを提案しています。これにより、依存関係が少なくなり、データオーナーシップの実行やオーケストレーションが向上します。

この革新的なアプローチは、データオーナーシップの概念を覆し、チームが異なるドメインのデータを複製し、それらのドメインをそのドメインに適した特定の形に変換することを提案しています。 

DDDコンテキストにおけるETL

抽出、変換、ロードは、データ統合の基盤であり、ビッグデータ分析に最適化されていないソースから、最適化されたデスティネーションシステムにデータをシームレスに移動させます。Eric Evans氏がDDDの概念を提唱する以前から、データ駆動型のチームは何百万ものビジネスドメインでETLパイプラインを使用していました。そのプロセスは次のようなものです。 

  • ETLは、データベースのメタデータ、Oracleの売上データ、オープンソースのリレーショナルデータベースのWebサービスデータなどの分析をサポートしていないデータソースからデータを抽出して集約します。
  • データを読み取り可能なフォーマットに変換します。
  • データを最終目的地（通常はデータウェアハウス）にロードします。
  • データエンジニアは、アナリティクスやビジネスアルゴリズムのための、使いやすく機動的なデータを手に入れます。

ここまでは、とても良いことです。 

しかし、DDDアプローチの支持者の中には、ETLの利点について言及する人はほとんどいません。あるいは、ETLについては全く触れていません。

ETLは様々な方法でDDDを活用します。ドメイン駆動型プロジェクトを実施するチームは、何百万ものオブジェクトとテラバイトのデータを扱います。これらのデータの多くは過去のものであり、多くのデータベースやソースに存在します。ドメインがデータセットを提供したりホストしたりするような分散型ではなく、ビッグデータパイプラインによって履歴データを処理し、ドメイン別のデータモデルに適したデータを集中的に保存する方がはるかに簡単です。少なくともこの文脈において、"Serve＆Pull "よりも "Push＆Ingest "の方が効果的です。

 

Eric EvansがDDDを概念化したのは約17年前ですが、それ以来、この概念は成長してきました。DDDを採用しているチームは、ドメイン別のデータモデルやデータモデルの背後にある論理やパターンを理解するために、過去のデータの文脈を理解する必要があります。ここでETLの出番となります。チームは、ドメイン別のデータモデルの品質に影響を与えることなく、データソースからデータをレイクやウェアハウス、そしてデータ分析ツールへと取り込むことができます。このような追加のデータインサイトは、ドメイン駆動型アプローチの妨げになるどころか、むしろ助けになります。 

ETLプロセスは完璧ではありません。例えば、ETLで最も一般的なデータソースであるリレーショナルデータベースからのデータを表現する際には問題がつきまといます。例えば、PythonやC++などのオブジェクト指向プログラミング（OOP）言語を使用したリレーショナルデータベースは、データを非常に具体的に表現します。OOP言語の中には、参照属性を使用するものや、他のオブジェクトで構成されたオブジェクトを持つもの、全くその他のものがあると、それらを扱うのは非常に面倒になります。 

エリック・エヴァンスはこの問題について著書の中で語っています。彼は、ソフトウェア開発者とドメイン間のコミュニケーションを向上させる「ユビキタス言語」を提唱しました。また、リレーショナルデータベースとは異なる方法でデータを保存し、OOP言語の問題を解決する「NoSQL」という造語も提唱しています。

最終的には、どのようなETLを使用するかにかかっています。適切なものは、言語の曖昧さを取り除き、ドメインモデルの整合性を損なうことなくデータを処理し、DDDのライフサイクルを最適化する方法でデータを一元化します。

Integrate.ioによるデータ変換がDDDに与える影響

Integrate.ioは、コード不要のクラウドベースのポイント＆クリック式ETLソリューションです。さまざまなデータストアやソースからデータを移動し、データを使用可能なフォーマットに変換（標準化の向上）して、リアルタイムのビジネスインテリジェンス分析の最適化のために最終目的地にロードします。DDDのコンテキストで使用する場合、Integrate.ioは、ビジネスプロセスのための分析によりドライブされるドメインの生データを準備します。ドメイン・ドリブン・デザインに加えて使用されます。

Integrate.ioのシンプルなAPIにより、ドメイン駆動型チームは、リレーショナルデータ、CSV、ウェブログ、CRMデータ、SaaSデータ、JSONなどのフォーマットを処理し、より効果的な分析とスケーラビリティを実現できます。また、このソリューションは、自動化やOOP言語の問題など、ETLにまつわる一般的な問題を取り除きます。テクノロジーにとらわれないプラットフォームとして、この強力なETLツールは、年齢や品質に関係なく、あらゆるタイプのデータを取り込みます。

Integrate.ioは、チームがデータドリブンであると同時にドメインドリブンになることをサポートします。

Recommended Reading: How Can Integrate.io Assist You as a Solution Architect? 

まとめ

 

DDDとETLは、適切なツールを選択する限り、両立することが可能です。DDDの提唱者の中には、データフローに対して分散型の「Serve＆Pull」アプローチを求める人もいますが、多くのソリューションアーキテクトチームにとっては、データを集中管理する方が生産性が高く、ソフトウェアのプロセスや機能を改善するための履歴データの測定や視覚化が可能になります。

エリック・エヴァンスは著書の中でETLワークフローについて触れていませんでしたが、その後DDDの概念は拡大し、データ統合はほとんどのチームにとって必要不可欠なものとなりました。したがって、ETLは、ドメイン駆動型の組織や企業にとって、もう一つのメリットを追加します。

Integrate.ioは、あなたのドメイン駆動型アプローチにどのようなメリットをもたらしますか？まずはオンラインデモを予約ください。