03.domain

変幻する実行可能知識 3

「わけるといふこと」

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

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

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

「ドメイン」とは専門用語としては「分野」や「領域」と訳されることも多いけれど, もともとは領土や邦のことだ. 領土ごとに使われている言葉や税金の取り立て方や風習がそれぞれ異なっている. モジュールやオブジェクトがある意味で均一な要素だったのとはそこが大きな違いだ.

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

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

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

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

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

  • まずは問題点 (ドメイン) を切り出しなさい
  • ドメインを分析して, そのドメインに適した言語でモデル化しなさい
  • その問題ドメインをアプリケーション・ドメインに変換する方法を考えて実行しなさい
  • そうすればうまくいくよ (多分...)

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

ドメイン・エンジニアリングは実はそんなに新しい考え方ではない. 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などを使うことができる.

今上げた一つ一つがドメインだと思っていい. いろいろなツールや言語をたくさん習得するのは大変な面も確かにあるけれど, 一度習得すればいろいろな利点がある.

  • 生産性をかなり向上させることができる
  • 知識がプログラミング言語で記述されたソース・コードの中に分散して埋没せず, 明示的な形で表されている
  • したがって知識資産としての価値がある
  • 知識の表現と, 表現された知識の変換 / 実行が分離されているので再利用性が高い
  • ドメインに適した表現を使うので知識の損失が少ない
  • ドメイン間の知識変換というメタな知識を明示的に蓄積できる

さて, 神様は退屈せずに済むだろうか...?

2004.04.05
山田正樹 (メタボリックス)

Comments