« 11/6,KOF2010にてユーザ企画講演 | トップページ | 個別案件にオブジェクト指向は要らない »

2010.10.23

「Smart UI」から「Smart DB」へ向かう道も険しい

 'Smart UI'とは、パネル制御をつかさどるプログラムに、データベース操作や業務ロジックやなんやかやがてんこ盛りになるような設計スタイルのことだ。Eric Evans著「Domain-Driven Design」で説明されているアンチパターンである。

 じっさい、このスタイルで設計されているデータベースシステムは多いし、傍目にはさまざまな利点があるように見える。データモデリングなんて理屈っぽい話など無視して「アジャイル」に作れば自然とそのようになってくれるし、プログラムの中身を見れば関連要素のあり方が一望できるように思えたりする。しかしこれがとんだクワセモノであることは、デスマーチから生きて帰ってこれたプログラマだけが知っている。そこらへんの事情は以下の記事で詳しい。

Smart UIについて、だらだらと(みねこあ)

Smart UIが優れている?(システム設計日記)

 では、Smart UIがダメだというのなら、どうすべきなのか。'Smart DB'を目指せばよい。パネル制御プログラム側ではなく、正規化されたデータベース側に業務ロジックを集約する。結果的に、プログラムが抱えるべき仕様の量が減ると同時に仕様全体の見通しが良くなって、システムの保守性が向上する。

 そんなふうに言葉で語るのは簡単だが、じつは個々の開発案件でSmart DBを完遂することは簡単ではない。なぜなら、JavaやRubyといった言語の利用を前提とした場合、Smart DBの方針は必然的に「ドメイン駆動開発」に向かうからだ。テーブルやフィールド毎にクラスやメソッドを用意して、ドメインのあり方を細密なクラス構造として表現し、実装する。開発者には高度なオブジェクト指向プログラミングの技術が求められる。

 たとえ優秀なプログラマを手配できたとしても、このやり方は最善ではない。できあがったソフトウエアの内部構造は伽藍のように美しかったりもするだろうが、喩えるならそれは「分子レベルの化合過程としてわかりやすくカレーの作り方を示した」ようなものだ。料理の出来上がり方のまとめかたとしてマチガイでないにせよ、どうにもアカデミックすぎて扱いにくい。大きな問題は、そのレシピが「家庭料理」でなく「化学」の文脈でまとめられている点だ。わざわざ化学者に頼まねばカレーのアレンジもできないなんて困る。コードの構成美を維持したままでカスタマイズをするために、わざわざオブジェクト指向のエキスパートに頼まねばならないなんてのは困る。あまりにアジャイルさに欠ける。

 けっきょくのところ、Smart DBも絵に描いたモチなのか――そういうことではない。そもそもSmart UIやSmart DBは「コード構成に関する議論」ではなく「仕様構成に関する議論」とみなすべきだ。仕様をまとめる際に、正規化されたデータベース上により多くの仕様が盛り込まれるように配慮する。そのための指針がSmart DBであると考えると、これを実現しやすくなる。

 オイオイ、システムの仕様をSmart DBの指針にしたがってまとめたとしても、それを実装してしまえばドメイン駆動開発と似たような結果になるのではないか――そんな反論があるかもしれない。たしかにプログラミング言語で実装すればそうだろう。しかし、仕様を実現する手段がプログラミングだけなどと考えてはいけない。ドメイン毎に用意されたある種のインタプリタ(私の言う「アプリケーションドライバ」)を用いて、仕様を「動的に実現する」という手がある。今後、このやり方が主流になると私は確信している。

 興味深いことに、私が開発しているアプリケーションドライバ「XEAD Driver」を用いた場合、実行中のデータ処理プログラムの処理域を眺めたなら、忌むべきSmart UI以外の何物でもないことがわかるだろう。

 どういうことか。XEAD Driverを用いた場合、テーブル仕様や機能仕様はSmart DBのスタイルでわかりやすくまとめられる(それが強制される)。しかし、これらの仕様データ(XMLで様式化されている)をXEAD Driverが読み込んで統合し、データ処理プログラムとして動的に立ち上げたとき、そのソフトウエアがSmart DBの構成をとるべき理由はなにもない。Smart UIだろうがSmart DBだろうが、はたまたDomain ModelだろうがTransaction Scriptだろうが、スパゲッティだろうがタコヤキだろうが、テキパキ動きさえすれば何でもよい。どうせそれは、セッションが終われば朝霞のように消えてしまう。

 大事なのは、アプリケーションドライバが上述の「家庭料理の文脈」をシステム管理者に提供する点だ。カレーのレシピをアレンジする際に化学者を手配する必要はない。同様に、システム仕様をカスタマイズする際にオブジェクト指向プログラミングのエキスパートを手配する必要はなく、データモデリングの文脈を理解していさえすればアジャイルにカスタマイズできる。「なんだ、データモデリングの習得は必要なのか」なんて言わないこと。それは多彩な家庭料理をつくるために「包丁を扱う技術」が求められるのと同じ話だ。複雑なデータベースシステムを開発するために「データ構造を扱う技術」が求められるのは当然だ。

 このように考えれば、「Smart UIかSmart DBか」という議論自体、ポイントがずれていることがわかるだろう。問題は、システム開発の際に「ドメイン固有の文脈を提供してくれる仕様インタプリタ」といった高級レイヤのプログラミングが完了しているかどうかだ。そういうものを用意せずに個別案件を毎回プログラミングすることにこだわる限り、「お手軽だが保守性の悪いSmart UI」か「洗練されているが敷居の高いドメイン駆動開発」か、というコーディングレベルの議論から抜け出せない。

|

« 11/6,KOF2010にてユーザ企画講演 | トップページ | 個別案件にオブジェクト指向は要らない »

コメント

アプリケーションプログラムの構造設計の手法として、Smart UI と DDD のいずれが優れているかの議論とは別に、アプリケーションロジックのうち、どれだけ多くを宣言的に記述できるのかの探求が必要なんでしょうね。

相当部分を宣言的に記述できるのであれば、その宣言的記述をもとにして、ソフトウェアのかなりの部分を動的にでも静的にでも生成することは可能と思われ、ひいては、アプリケーション開発自体、今よりずっとライトなものとすることができるはずです。その意味で、宣言的に記述できるアプリケーションロジックの範囲を少しずつ広げて行く営為が必要かつ適切と思われるのですが、一般的には、そうしたことはなされていないように思います。何がそれを妨げているのでしょうね。

投稿: keis | 2010.10.24 21:12

keisさん

業務ロジックの宣言的記述にもっとも向いているのは、何といってもプログラミング言語でしょう。でも、だからといってオブジェクト指向プログラミングでシステム仕様を表現するのってのは大げさすぎる。記事中の「高級レイヤ」のような基盤系ソフトウエアの開発に、オブジェクト指向プログラミングは向いています。だけど、個別開発案件におけるSmart DB上の業務ロジックは手続き型プログラミングで記述できてしまいます。

だから、Rhino(Javaの中でスクリプト言語を動作させるためのエンジン)は画期的だったと思います。これが登場したとき、業務システム開発においてオブジェクト指向プログラミングと手続き型プログラミングとをどう使い分けるかの方針が開発実務のレベルで明確になった。XEAD DriverもRhinoなしでは成り立ちません。ありきたりですが、この方向の探求が始まるには、プログラミング技術の発展を待つ必要があったのではないでしょうか。

投稿: わたなべ | 2010.10.25 15:23

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「Smart UI」から「Smart DB」へ向かう道も険しい:

« 11/6,KOF2010にてユーザ企画講演 | トップページ | 個別案件にオブジェクト指向は要らない »