電通国際サービス 開発技術センター 統括マネージャー(Seasarファウンデーション Chief Committer) 比嘉康雄(ひがやすを)氏

UMLモデリング推進協議会(UMTP/Japan)は14日および15日、大手町サンケイプラザにおいてモデリングに関するフォーラム「Modeling Forum 2006」を開催した。同フォーラムでは2日間にわたってUML、モデリング、SOA、SOX法、内部統制などに関する幅広いセッションが催される。ここでは、電通国際サービス 開発技術センター 統括マネージャー(Seasarファウンデーション Chief Committer)比嘉康雄(ひがやすを)氏によって発表された「EJB3時代のアーキテクチャパターン」についてとりあげたい。

Webアプリケーションにおける従来のJavaの開発は、いわば「レイヤモデルアーキテクチャ」、と同氏は説明する。レイヤそれぞれに役割があり、それに徹するというものだ。プレゼンテーション層、サービス層、データアクセス層、ドメインモデルのように層がわかれ、レイヤの間をモデルが流れるという仕組みである。これらフレームワークにはいくつか問題が指摘されている。代表的な問題は次のとおり。

• 入力値とドメインモデルの変換が面倒
• 設定ファイルの記述が面倒
• Servlet APIに依存しているためテストが面倒
• Open Session in Viewでリダイレクトリが使えない

サービス層ではPOJO(Plain Old Java Object)が使われることが多く、実装はインターフェースに依存していることが多い。トランザクション制御（DIコンテナのAOPを利用）やドメインモデルと永続コンテキストの関連付け、ドメインモデルロジックの呼び出し、ドメインモデルをDAOから取得するなどの作業をおこなう。

サービスはアクションごとに1つづつ作成することが多く、多くの場合サービス同士は関連を持たない。仕様を明示する意味でインターフェースを使うことが多いが、同一のユースケース内での採用であればインターフェースの必要は薄いかもしれないという。

データアクセス層(DAO: Data Access Object)ではHibernateが代表的なフレームワーク。フレームワークに依存した実装になるのが特徴的。DAOはテーブルごとに作成され、複数のサービスから利用されることが多い。DAO同士は関連を持たない。実装にインターフェースが採用されるのは、試験時と本番時で実装を入れ替えることが容易という理由がある。

ドメインモデルもサービスと同様、POJOが採用されることが多い。ツールによって抽象クラスが自動生成され、その抽象クラスを継承して業務ロジックを記述するといったやりかたをする。ドメインモデルではこれまでと異なり、インタフェースを使わないことが多い。これは直接実装をnewすることが多いことや、状態(プロパティ)へのアクセスが多いため、インタフェースはあまり適さないためである。

DIコンテナはオブジェクトの生成や関連を管理するプロダクトで、各層のオブジェクトを関連付ける働きをする。代表的なフレームワークとして同氏はSpirng FrameworkやSeasar2をあげている。問題は設置が面倒なことが多いということだ。

これらレイヤモデルアーキテクチャは、最初に述べたようにプレゼンテーション層における問題点がそのまま全体の問題となる。