ドメイン・エンジニアリング温故知新：実行可能な知識とソフトウェア（3）

ソフトウェア開発とは問題ドメインの知識をアプリケーション・ドメインの知識に変換することだといってもいい。（本文より）

» 2004年05月08日 12時00分 公開
[山田正樹，メタボリックス]

　ソフトウェア開発方法論とは「いかにしてシステムを分割するか」という“教え”そのものだった。構造化パラダイムしかり。「ソフトウェアをモジュールに分割せよ、分割せよ、分割せよ。して、その方法は……」。“……”の部分は100人の構造化信者がいれば、100通りのお告げがあった。そしてまた、オブジェクト・パラダイムしかり。「ソフトウェアをクラスに分割せよ、分割せよ、分割せよ。して、その方法は……」“……”の部分は100人のオブジェクト信者がいれば、100通りのお告げがあるのである。

　最近、ソフトウェア開発方法論の神様は少し退屈していた。世の中、おしなべてオブジェクトばかりなのはよいとしても、神様の本当の出番があまりなかったから。みんなオブジェクトの称名（しょうみょう）には熱心だけれど、修行に励む者は少なく、やれ「バグが少しでも減りますように」だの、やれ「プロジェクトが少し遅れてもいいので、なんとか納品までこぎ着けますように」だの神頼みばかりだったから。

　そこで神様は昔の帳面をひっくり返し、新しい信心のお題目を探し出すことにした。昔の帳面から新しい言葉を引っ張り出すというのはいささか変だけれど、神様だから仕方ない。この帳面には過去から未来に至るまで、ありとあらゆる言葉があらかじめ書き込まれているのだ。そこで神様は「ドメイン（domain）」という何やら有り難げな言葉を見つけ出してきた。

　「ドメイン（domain）」は専門用語として「分野」「領域」と訳されることも多いけれど、もともとは「領土」や「邦（ほう：国家、国土）」を意味する言葉だった。世界を見回すと、「領土」ごとに使われている言葉や税金の取り立て方、風習が異なっているのが分かるだろう。モジュールやオブジェクトはレゴ・ブロックのようなもので、 1つ1つの部品はもちろん異なっているけれど、どの部品を取っても同じ思想や論理が貫かれている（はずだ）。だからいくらでも組み合わせていける。でもドメインは、その1つ1つが異なる論理によって支配されている。1つのソフトウェアの中にさまざまな異なる文化を見つけ出すのがドメインというわけだ。だからドメインを考える場合には、ドメインとドメインをどうやってつなぐかも考える必要がある。

　ソフトウェアは、均一なモジュールやオブジェクトで成立している、というのも1つの考え方だけれど、そういう考え方は「モダニズム（近代主義）」といって、一種の理想化にほかならない。特にソフトウェアを作る過程を考えると、最初から均一なモジュールやオブジェクトというものが存在していて、それを組み合わせるだけで一丁上がりというわけにはいかないことがよく分かる。これから作ろうとするソフトウェアをあっち側から、こっち側から、遠くに離れて、虫眼鏡を使って、いろんな見方をしないと良いものは作れない。

　普通、ソフトウェア工学で単に「ドメイン」というと、「問題ドメイン」を指すことが多い。問題ドメインとは、これから作るソフトウェアが解決しなければならない問題の発生している場所のことだ。例えば、電子カルテ・システムを作ろうとしたら、問題ドメインは、電子カルテの使われる病院という現場に関する知識の全体を指している。もっと技術寄りの問題ドメインもある。例えば、さまざまなソフトウェアで、共通で使われるトランザクション管理というのも1つの問題ドメインと考えることができる。

　一方、問題ドメインと組になるのが「アプリケーション・ドメイン」だ。アプリケーション・ドメインとは、問題ドメインにある問題を解決するための知識全体のことだ。ソフトウェア開発とは問題ドメインの知識をアプリケーション・ドメインの知識に変換することだといってもいい。

　いままでのソフトウェア開発はアプリケーション・ドメインに重点を置き過ぎていた。もちろんわれわれソフトウェア開発に従事する者たちは「問題解決のプロ」なんだから、それは当然だろう。でも、何が問題かを的確に把握できなければ、問題を解決することなんてできっこないということも分かってきた。それと同時に、ドメインとはそれぞれ異なる論理によって支配されている領域なわけだから、すべてのドメインを1つの概念／考え方／言語で表すのは難しいということも分かってきた。例えば、アプリケーション・ドメインの知識を表すために、あるプログラミング言語が役立つとしても、同じプログラミング言語で問題ドメインの知識をうまく表せるとは限らない。

　結局、ソフトウェア開発がうまくいかない最大の問題は「何を解決すればいいかが分からない」という点だ。要求がはっきりしない、顧客が何を考えているか分からない、何が問題なのか分からない。逆にいえば問題をはっきりさせることができれば、それを解決するのはそんなに難しいことではない（かもしれない）。だから、

まずは問題点（ドメイン）を切り出しなさい

ドメインを分析して、そのドメインに適した言語でモデル化しなさい

その問題ドメインをアプリケーション・ドメインに変換する方法を考えて実行しなさい

そうすればうまくいくよ（多分……）

というのが、ドメイン・エンジニアリングの考え方なのである。

　ドメイン・エンジニアリングは実はそんなに新しい考え方ではない。1990年代前半に起こった考え方だ。モデル駆動開発、アスペクト指向プログラミング、プロダクト・ラインなどの考え方の先祖だといってもいい。10年前、ドメイン・エンジニアリングは普及しなかった。でも、10年後のいまは少々事情が違う。

UMLのおかげでモデリングというものがよく理解されるようになってきている

MDAによって問題ドメインからアプリケーション・ドメインへの変換技術が普及してきている

さまざまな分野ごとに切り出されるドメインの境界が定型化してきている

　例えば、あるビジネス・アプリケーションを開発することを考えてみよう。われわれはまず、顧客と一緒にビジネス・モデルを作り始める。UMLのアクティビティ図やクラス図を使ってビジネス・モデルを表現することがあるかもしれない。エンタープライズ・アーキテクチャの考え方では、「Zachmann Framework」という表記法を使うこともある。この段階のビジネス・モデルは、ソフトウェアの素人である顧客もよく理解できるように記述されなければならない。UMLで記述するとしても、ソフトウェア設計に使う場合とは使い方がかなり違うはずだ。

　ビジネス・モデルだけではもちろん動作するソフトウェアにはならない。ビジネス・モデルをRDBに格納するために、われわれはビジネス・モデルからE-Rモデルを抽出する（うまくいけば自動的にできる）。Javaでビジネス・ロジックを実装するためにはUMLでクラス図を描く。もしほかのシステムと連携させる必要があれば、ビジネス・モデルからXMLモデル（スキーマ）を生成させるだろう。ビジネス・ルールが「if〜then〜」というような形でうまく表現できるようなら、この部分をJavaで直接コーディングするのではなくルール・エンジンを使って直接「if〜then〜」ルールを解釈／実行できるようにする場合もある。ビジネス・ワークフローが状態遷移として表せるのならば、状態遷移図を読み込んで実行できる状態機械コンパイラを使えばよい。このように、モデルからモデル（あるいはJavaコード）への変換には、RelaxerとかXSLTとかEMF（Eclipse Modeling Framework）やマクロ・プロセッサのVelocityを使うことができる。

　上に挙げた1つ1つをドメインだと思っていい。つまり、ビジネス・モデル、E-R構造、静的構造、情報構造、ビジネス・ルール、ワークフローなど。いろいろなツールや言語をたくさん習得するのは大変な面も確かにあるけれど、一度習得すればいろいろな利点がある。つまり、

生産性をかなり向上させることができる

知識がプログラミング言語で記述されたソース・コードの中に分散して埋没せず、明示的な形で表されている

従って、知識資産としての価値がある

知識の表現と、表現された知識の変換／実行が分離されているので再利用性が高い

ドメインに適した表現を使うので知識の損失が少ない

ドメイン間の知識変換というメタな知識を明示的に蓄積できる

　さて、神様は退屈せずに済むだろうか…？

著者プロフィール

山田正樹

（株）ソフトウェア・リサーチ・アソシエイツ 、（株）ソニーコンピュータサイエンス研究所を経て、1995年（有）メタボリックス設立。代表取締役。アーキテクチャ、モデリング、マネージメント、コラボレーションなどを含む広い意味でのソフトウェア・プロセス・エンジニアリングが専門。ソフトウェア・ツール開発、メンタリング、コンサルティングなどを行っている。



「実行可能な知識とソフトウェア」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ