データ分析におけるドメイン起点での設計の流れ：第二弾

はじめに

本記事の立ち位置

本記事は、データ分析基盤構築のための設計方法について整理したものです。
ソフトウェア開発手法の一つであるドメイン駆動設計（Domain-Driven Design、以下DDD）を用いて、データ分析基盤を構築するための考え方と方法論について説明を試みたものです。また、本記事は三部構成のうちの第二弾です。第一弾では主に、実際のデータ分析基盤を構築する上での問題提起と前提について整理しました。興味のある方はこちらもどうぞ。

ソフトウェアを開発する上で、常に意識しないといけないことは、
「ソフトウェアは、実世界の作業を自動化したり、ビジネス上の問題を解決する」ためにあるということです。ソフトウェアを作ることがソフトウェアを作る目的ではありません。
DDDは設計という名前を冠していますが、その対象範囲はエンジニア（開発者）だけに留まりません。

DDDで重要なことは、開発者以外も、作りたいソフトウェアへの関心を持ち、モデリングをしていくことにあります。

本記事の目的

– データ分析基盤でDDDを実践するに必要な用語を整理すること。
– どのように考えて、コミュニケーションをすれば良いのかを言語化すること。

目次

1. ドメイン駆動設計を用いてデータ分析基盤を設計する
1.1. ドメイン駆動設計の目的
1.2. 概念
1.3. 登場人物
2. データ分析基盤におけるDDDのフロー
2.1. DDDのフロー
2.2. ドメイン知識を抽出する
2.3. 目的を決定する
3. まとめ

1. ドメイン駆動設計を用いてデータ分析基盤を設計する

DDDは、ソフトウェア解決手法の一つです。
ソフトウェア化する対象（業務領域）を「ドメイン」と呼び、ドメインの専門家と開発者が協同して設計・開発を進めていくことを重要視した考え方です。
ソフトウェア設計というと、コードやインフラの設計をイメージする方が多いと思います。
しかしDDDは、技術的な方法論のみへの洞察ではありません。
なぜなら、ソフトウェア開発において、「どう作るか」よりも、「何を作るか」の議論が重要だからです。「何を作るか」が曖昧で、不明瞭で、本質的なものでなかった場合、そのソフトウェアの存在意義が問われます。

本記事では、すでにソフトウェア開発手法として十分な歴史と実績のあるDDDに少し手を加える形で、データ分析基盤の設計方法を確立することを目指します。

説明のため、本章ではDDDの目的や、用語を整理することから始めたいと思います。
データ分析基盤におけるDDDには、2つの概念と3つの役割があると考えます。

2.1. ドメイン駆動設計の目的

DDDは次の目的で構成されます。

①実務をしっかり理解した上でシステムを設計し、リリース後もちゃんと使われるものを開発すること（モデル化）
②修正が容易なシステムを作ること（コード化）

問題解決領域（ドメイン）→モデル（設計図）→コード（プログラム）
の順で説明します。
①を満たすためには、ドメインをモデル化することが重要です。
②を満たすためには、モデルをコード化することが重要です。
本記事では②の、どのようにモデルをコード化するかについては説明しません。
主に①の実務を理解した上で本当に必要なシステムを設計するための方法を考えます。

1.2. 概念

DDDには、「ドメイン」という概念があります。

1.2.1 ドメイン

ドメインは問題領域と解決領域を持っています。

現実世界はドメインに対応し、問題領域と解決領域に分類される。

1.2.2 コアドメイン

問題領域のうち、事業的に重要で戦略的に不可欠なもので、システム化する価値の高いものに分けたもの。

問題を解決するための方法をモデル化する。

1.2.3. ドメインモデル

コアドメインを実際にどう解決するか定義したもの。
本記事では触れませんが、ドメインモデルは、コードにすぐに落とし込める状態になっています。

1.3. 登場人物

設計にあたり、必要な人物を説明します。

ドメインエキスパート

ドメインに対して深い知見がある人。
データ分析であれば、そのデータの周辺にある世界に対して深い理解がある人。ドメインに対しての知識を多く有し、他の人々に専門的な知識を提供し設計と内容に矛盾が無いようチェックするインファレンス能力に優れている人物であることが望ましい。

ビジネスエキスパート

ビジネスにおいて、予算に対しての決定権を有する人。
コストに対して責任を持つことができる人。

アナリスト

得られたデータを適切に分析し、意義のある示唆を抽出する人。
ドメインに対しての汎用的な分析スキルを使用して、意味のある解釈を行う人。

エンジニア

ソフトウェア（ロジックやデータベースなど）を作る人。
ものづくりを専門とし、どのように期待されるシステムを作り上げるかを考えることができる人。

2. データ分析基盤におけるDDDのフロー

2.1. DDDのフロー

DDDでは、次の手順に沿ってシステムを設計します。

a. ドメインの知識を集め、時間を共有し議論する
b. モデルに基づいて共通言語を洗練させる
c. モデル化（ドメインエキスパート）
d. モデルを蒸留する（全員）

各ステップでは、すべての役割間でコミュニケーション出来るようなドキュメントを用意し、認識齟齬を防ぐようにします。

本記事ではデータ分析基盤の構築を目指しているため、DDDを実際のデータ分析に合わせて拡張していきたいと思います。

①ドメインエキスパートがドメイン知識を抽出する。（コアドメインの問題領域を選定）
②ドメインエキスパートが、目的を決定する。（コアドメインの解決領域を選定）
③目的を達成するための具体的な解決策を検討する。（モデル化）
④ドメインエキスパート、アナリスト、エンジニア間で会話するための齟齬のない共通言語を作る。（ユビキタス言語と呼ばれるすべての役割間で統一された言語を定義）
⑤抽出されたドメイン知識を元にモデルを作成する。（UML図などの設計図）

①〜⑤を繰り返し、修正・検証しながら洗練していきます。

設計図の例
ER図、テーブル図（関係者がイメージしやすいために）
シーケンス図（時系列として各役割を整理したもの）
クエリ例（どのようなデータ分析がしたいかを具体例とともに）

2.2. ドメイン知識を抽出する

コアドメインの問題領域を選定します。
現実の世界がどのような問題を抱えているのかを明確にします。
ドメインエキスパートが主導で、ビジネス課題をビジネスエキスパートと協議し設定していきます。

2.3. 目的を決定する

問題に対しての整理が完了したら、解決策（解決領域）を考えます。
ここでは、ソフトウェアのコードやインフラは考えず、大きな方針を決定します。

3. まとめ

本記事では、データ分析基盤におけるDDDの流れについて説明しました。
第三弾では、どのようにドメインエキスパートや開発者が連携してコミュニケーションしていけばよいかを、具体的なドキュメント例やフレームワークを使って説明していきます。

参考

・cf．[ドメイン駆動設計によるシステム開発 生産ラインのイノベーション]
・『エリック・エヴァンスのドメイン駆動設計』, エリック・エヴァンス, 翔泳社, 2013. Accessed 18 January 2022.