データモデルはドメインモデルに先行する

　関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。

　どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。

　これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させるべきか。データモデリングである。

　これまでも私は、アプリ設計をDB設計に先行して進めるというアンチパターンに関して何度も警告してきたが、ドメインモデリングをデータモデリングに先行させるというのは、そのアンチパターンの類型に他ならない。他の分野では知らないが、テーブルを数十個以上含むような業務システムの開発でこれをやってはいけない。

　なぜか。業務システムというものが、「複雑精妙な構造を伴うDBを核とするソフトウエア」だからだ。それゆえに業務システム開発におけるデータモデルは、高層ビル建築における基礎構造や鉄筋構造の図面に相当する。これをまとめることをスキップしてどんなに緻密に外観を描き倒しても、構築物のフィージビリティが向上するわけではない。

　別の言い方をしよう。業務システムというものは、私の言う「三要素」、すなわち、

・複雑精妙な構造を伴うDB（データ構成）
・DBに対してさまざまなデータ処理を行うアプリ（機能構成）
・アプリを用いて既定の手順で仕事を遂行するユーザ（業務構成）

の相互関係としてモデル化できる。これらのうち「データ構成」は、アプリの実装方式に基本的に影響されない。

　当たり前の話だ。アプリ部分をJavaで作ろうが、関数言語で作ろうが、超高速開発ツールで作ろうが、はたまたCOBOLで作ろうが、DB構造はほとんど影響を受けない。DB構造というものは、業務要件にもとづいてそのシステムがどんな情報を管理すべきかによって決まるのであって、アプリ部分がどの言語で組まれるかには影響を受けない。もしDB構造を強く規定するとしたら、実装方式としてスジが悪い。言い換えれば、どの言語で組むとしても影響を受けない形にまとまったと思えるなら、DB設計の成果としてマトモなのである。

　この単純な事実は、我々に大切なことを教えてくれる。オブジェクト指向言語での開発を前提としようが、関数言語での開発を前提としようが、COBOLでの開発を前提としようが、はたまたWEBアプリだろうがデスクトップアプリだろうが、アプリ構造の検討を先行させても、その成果物からDB構造は導けないということだ。アプリ構造というものはあくまでも「DB構造」と「実装方式」の組み合わせで決まる。つまり、アプリ構造からはDB構造を一意に導けない（次図）。

　　　　　　　　　▼アプリ構造はDB構造と実装方式から導かれる

　自明にもかかわらず、なぜ多くのプロジェクトが「とりあえずアプリの構造を明らかにすれば、あるべきDB構造も見えてくるに違いない」といった希望的観測で、アプリ（クラス構造と言い換えてもいい）やUIの設計に取り掛かってしまうのか。

　理由は単純だ。多くの技術者にとって、DB設計という課題が何やらメンドウで得体の知れないものだからだ。それゆえ、アプリやUIの設計を先行させればプロジェクトとして動き始めたように思えるし、少なくとも初期段階ではおおいに進捗していると上長に報告できるからだ。結果的に、DB構造がグダグダになって、それをゴリゴリのロジックでカバーして、心身ともクタクタになるといういつものデスマーチが始まる。

　これはまた、DB設計を先行させながらそつなくこなせる要員が稀少ということでもある。だからこそ、業務システム開発に携わる技術者に提案したい。まずはシステム要件に対して確実にデータモデリングできるようになろう。そのスキルは将来のキャリア上の選択肢を広げてくれるだろう。個々のプロジェクトにおいてデータモデリングがドメインモデリングに先行するように、スキルアップにおいてもデータモデリングを先行させよう。