Life is beautiful

　最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。

　もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。

　そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）。

　クライアント側でJavaScriptが実行できないようなブラウザーに対しては、サーバー側にControllerをおいてView TemplateとModelの結合を行って生成したHTMLを返す。JavaScriptが実行できるブラウザーに対しては、あえてサーバー側にはControllerをおかず（もしくは最小限のものにとどめ）、JavaScriptで記述されたControllerをブラウザーに送り込み、HTMLで記述されたView TemplateとJSONの形で送られて来たデータとの結合はクライアント側で行う（先日のjQBinder参照）。

　こんな風に作る一番の利点は、Modelへのインターフェイス作りをさぼることが絶対にできなくなること。ブラウザーのタイプによって二つの異なるView/Controllerペアとやりとりをしなければならないのでインターフェイスの明確な定義は必須だし、Statelessで非同期なインターフェイスなので、データの整合性を守るための複数のテーブルにまたがったトランザクションは絶対にModel側でしなければならないことはプロジェクトに関わる全員に自明となる。

　また、Modelはデータベースやサーバー側のハードコアなプログラミングに慣れたエンジニアが担当し、View/Controllerは見た目やユーザーインターフェイスにこだわるエンジニアが担当する、など作業分担もしやすくなる。

　それに加えて、Modelのインターフェイスが特定の言語に依存しないため、ModelはJavaで（サーバー側の）ControllerはPHPでとか、各モジュールのモックアップをRailsでアジャイルに作ってから本来の言語で本実装をする、などのテクニックが使えるのも利点だ。

　もちろん、これもデザイン・パターンの一つでしかないので、どんな場合にも適用できる話ではないが、少なくとも私が関わっているプロジェクトのほとんどすべてにこのアーキテクチャが適用できそうだな、と思っている今日この頃である。