« X-TEA Driverが1.3にリリースアップ | トップページ | 拡大・縮小する前に美しいER図を »

2016.03.11

フレームワークとドメイン特化基盤

 JavaやRubyは「汎用プログラミング言語」であって、これを使えばたいていのソフトウエアを作れる。ゲームソフトも、組み込みソフトも、業務システムも、バンドのリズムセクションの自動演奏音源だって作れる。すばらしい。しかしこれは、汎用プログラミング言語の使い方として適切なのだろうか。

 それらのソフトウエアは、いずれかの「ドメイン(ソフトウエアの分野)」に分類される。同一ドメイン内のソフトウエア群であれば、同一の特性を具えている。その共通特性にもとづいて、開発過程を合理化するための枠組みを想定できる。

 そのような枠組みとして、もっとも素朴なものが「クラスライブラリ」だ。当該ドメイン向けに便利なクラス群をあらかじめ用意しておくのである。それらにテンプレート機能等を組み込んで整備すれば「アプリケーション・フレームワーク(APFW)」と呼ばれるものになる。

 ドメインに対する合理化の営為はこれで終わらない。じっさい、演奏音源をJavaのAPFWで開発しました、なんて話は聞かない。プログラミング言語のコードではなく「演奏シーケンス」を書けば、インタプリタが自動演奏してくれる――そんな制作環境がいくらでもあるからだ。

 その場合、演奏シーケンスは「ドメイン特化言語(DSL,Domain Specific Language)」で記述される。ただし、その内容をテキストエディタあたりで編集するのは面倒なので、GUIを駆使した専用エディタがあったほうがいい。そんなエディタとインタプリタとが統合された開発環境が、私の言う「ドメイン特化基盤(DSP,Domain Specific Platform)」だ。演奏音源を制作するためのDSPとして有名なものは「初音ミク」や「Sonar」である。

 そういったDSPが、各ドメインで遅かれ早かれ生み出される。専用のエディタを使って「案件記述」をまとめると、専用のインタプリタがそれを解釈して、想定された仕様のソフトウエアとして動作する。その合理化効果はAPFWと比べて桁違いである。ドメイン内の共通問題への対処がDSPに委譲されるため、「案件開発者」としては個々の案件に固有な問題に集中できるからだ。

 合理化される以外にもさまざまな効果がもたらされるが、それはDSPとAPFWとの本質的な違いとして説明できる。まず、APFWにおける「案件記述」は、APFWの開発言語を使ってコーディングされる。オブジェクト指向言語のAPFWであれば、案件記述はオブジェクト指向でまとめられる。関数型言語のAPFWであれば、案件記述は関数型言語の枠組みでまとめられる。

 いっぽうDSPにおいては、それがどんな開発言語で組み立てられたかに関係なく、案件記述はドメイン固有の枠組み(DSL)で端的にまとめられる。したがってDSPのユーザには、オブジェクト指向言語や関数型言語の知識は要らない。初音ミクやSonarのユーザは「テンポの変化はどのクラスに記述しようかな」などとは悩まない。

 ようするに、APFWとDSPの本質的な違いは「開発言語の特性が案件記述に浸出するかどうか」にある。「案件と基底部とのくっつき方の違い」といってもいい。DSPは案件記述と汎用プログラミング言語の処理系との間に「立ちふさがる」形で機能するが、APFWでは本体部分と案件部分とが連続した形で処理系の上に載っている。結果的にDSPでは、付加される部分だけが案件記述を成すため、APFWに比べて定義体のサイズが桁違いに小さくなる。

 開発者の要件も明確になる。初音ミクやSonarのユーザは案件のクラス構成について悩まないが、その代わりに「ドメインエキスパート」としての自らの能力(音楽的な適性や熟練度)をどれだけ案件に投入できるかに呻吟する。この意味でDSPは、案件開発者の「ドメイン親和性」をはかるリトマス紙である。つまり、DSPは強力な合理化手段ではあるが、これを使えば誰でも開発できるというものではない。

 じつはこれは、DSPを使うかどうかには関係ない。たとえば「音源」を開発するには、DSPを使おうがOOPでやろうが「音楽的なセンスやスキル」が要る。DDDの提唱者は「そこらへんはドメインエキスパートにまかせたらいい」と言うが、そんな恵まれたプロジェクトがどれだけあるだろう。まずは開発者自身がドメインエキスパートとして、クライアントの素人っぽい要求に沿って案件を仕様化できるようでなければいけない。この当たり前の事実が、汎用プログラミング言語を使って開発するスタイルでは見えにくかっただけの話だ。

 このようにDSPの効果を語ると「特定のDSPにロックインされるリスクがある」と反論されることがあるが、杞憂である。同一ドメインであれば、DSP間のDSLの違いは小さいからだ。また、「テーブル操作と業務ロジックの連動制御」の記事でも説明したように、DSPにはそれぞれの案件のあり方をわかりやすくまとめるための「ドキュメンテーションツール」としての側面があるからだ。むしろ、DSPへのロックインよりも、開発言語やAPFWへのロックインのほうを心配したほうがいい。案件記述のDSP間のコンバージョンに比べたら、開発言語間やAPFM間のコンバージョンのほうがはるかにやっかいなのだから。

 良いことづくめのようだが、DSPにも問題がないわけではない。DSPを利用することで、たとえばオブジェクト指向プログラミング(OOP)を得意とする技術者にとっては、スキルを行使する機会が減ってしまう。かといって、APFWあたりを駆使しつつ丹念にOOPするスタイルにこだわっても、DSPを使いこなす競業者(つまりドメインエキスパートを兼ねる開発者)の提案に勝てるとは限らない。

 そんな懸念を持つ技術者にはアドバイスしたい。得意とするドメイン向けのDSPを、OOP(関数型言語プログラミングでも何でもいい)してしまおう。DSP上でのライトな案件開発と、IDE上でのヘビーなDSP開発とに同時に関われるようになる。これは楽しい。それを実践している本人が言うのだからほんとうだ。

|

« X-TEA Driverが1.3にリリースアップ | トップページ | 拡大・縮小する前に美しいER図を »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: フレームワークとドメイン特化基盤:

« X-TEA Driverが1.3にリリースアップ | トップページ | 拡大・縮小する前に美しいER図を »