REST的な内部アーキテクチャ

はじめまして。アーキテクトのQZ西垣です。 今回は、現在製造中のシステムにおけるアーキテクチャについてお話しようと思います。

REST is Hot!

Web開発におけるアーキテクチャスタイルのひとつとして、最近はRESTが熱いようです。
RESTとは簡単に言えば、

• レスポンスを得るために必要な情報は、全てリクエストに含まれる
• リソースは状態を持つ

といったところでしょうか。 （詳しくは“Wikipediaなどを参照してください）

フレームワークに依存しないビジネスロジック

さて、弊社では、Javaを使用してソリューションを構築する際、TomcatとStrutsを使用しています。
枯れているが故の安定感はありますが、フレームワークとしてはすでに古い部類に属しています。
また、Javaという言語自体が、近代化の波に乗り遅れている感があります。
（最近若干キャッチアップしてきたようですが）
そのため、ScalaとPlay Frameworkによる開発も検討しています。
しかし、いきなり開発言語とフレームワークを切り替えるのは、開発におけるリスクがあまりにも高い。
そこで、環境を少しずつ変更していくことにしました。
まず今回は、言語はそのままJavaを使用することとします。
一方で、実装において、ビジネスロジックからフレームワークへの依存を排除し、フロントエンドを切り替え可能な設計としました。
さらに、データベースの操作は、ビジネスロジック内ではインターフェイスのみ宣言し、実装はフレームワーク等の環境依存にします。

REST的な発想を内部構造に持ち込む

ここで生きてくるのが、REST的な発想です。
ビジネスロジックオブジェクトは、オブジェクト化されたパラメータのみをインプットとし、エンティティとしてのデータベースの操作を実施します。
HTTPリクエストやHTTPレスポンス、セッションなど、環境に依存する入出力系から切り離すことにより、ビジネスロジックはシンプルかつデバッグしやすくなります。
また、将来、HTMLのフォームによるページ遷移を伴う処理から、AjaxとWebAPIによるバックグラウンド処理へと切り替える際にも、修正は比較的少ない作業量で済みます。
当然、前述のとおり、フレームワークの切替もスムースに行うことができるでしょう。
全体としてコードの量は増加しますが、個々のクラスの独立性が高まり、構造は強固になります。

歴史は繰り返す

REST的な設計手法は、プログラムの内部構造にも有用であるという話でした。
かつて、オブジェクト指向的な設計が、あらゆる場面で有用とされたのと似ていますね。
そして、今はまだ見えませんが、いつかきっとRESTを超えるものが現れるのでしょう。