ページ駆動開発とテーブル駆動開発

Seasar2.3の時代は､Goyaと言われる開発手法がありました。Goyaのアーキテクチャは､JavaEEの基本にのっとったレイヤモデルアーキテクチャです。詳しくはこの辺。
http://d.hatena.ne.jp/higayasuo/20050817#1124260949
http://d.hatena.ne.jp/higayasuo/20050818#1124338844
役割分担がきちんとされているきれいなアーキテクチャだと思うのですが、CRUD(Create Read Update Delete)しかないような単純な画面でもそこそこクラスが必要で重い感じがするのも事実です。
過去のDIではインターフェース中心の設計が強く推奨されていたため､レイヤモデルアーキテクチャは重く感じられても非常にDIにフィットしていました。
しかし、Javaでさらに生産性を高めるためには､レイヤモデルアーキテクチャは重くて足かせになります。そこで考えたのが「ページ駆動開発」と「テーブル駆動開発」です。これらの開発手法は､Churaファミリーを使って行います。
ページ駆動開発は､UI(ページ)を軸として開発を進める方法です。ページ駆動開発は､次のような手順で行われます。

• ユーザとHTMLなどのUIモックを使ってレビューを行う
• レビュー済みのUIモックから項目を抽出してデータベースモデリングを行う
• UIモックに規約に従ってid属性をつける
  • 入出力項目は､カラム名をid属性に設定する
  • ボタンはメソッド名をid属性に設定する
• UIモックからDoltengを使ってPageクラスを自動生成する
• メソッド以外は自動的に出来上がっているので､ユーザの要件に応じてメソッドの中身を実装する

実装する必要のあるクラスは基本的にPageクラスのみ。そのPageクラスもメソッドの部分を埋めるのみですみます。画面固有のロジックはPageクラスに記述します。複数の画面で共通に使うロジックのみインターフェースを使うようにして外側のクラスに切り出すのです。PageクラスはPOJOなのでインターフェースを使わなくてもテストがしにくくなることはありません。複数の画面から使われるクラスは、やりたいことを明確にするためにインターフェースを使います。Pageクラスは画面固有なのでやりたいことが初めから明確です。わざわざインターフェースを使う必要はないのです。
データベースにアクセスするクラスは､Daoとしてインターフェースを定義します。実装クラスはAOPで自動生成されるので開発者が書く必要はありません。このDaoもDoltengが自動生成してくれます。
やることはこれだけ。非常にシンプルではないでしょうか。
テーブル駆動開発は､ページ駆動開発を補うものです。ページ駆動開発をしているとマスターメンテ画面などユーザと特にUIモックを使ってレビューする必要のない画面が出てきます。そういう画面は､テーブルのメタデータより自動的に画面を作成するのです。
重要なことは､テーブル駆動開発はあくまでもページ駆動開発の補助的な役割だということです。実際の開発を考えてみてください。ユーザが興味のあるのは画面であり､テーブルではありません。だったら最初にレビューをする必要のあるのは､画面でしょう。後は､その画面の情報よりPageクラスを自動生成すればよいのです。
ロジックは「Pageに書くで良いじゃん」というのが今の私の考え。プレゼンテーションモデル(Page)にロジックを記述するとロジックの再利用性が悪くなると思う方もいるかもしれません。あくまでもPageクラスに記述するのは､画面固有のロジックです。再利用する必要はないのです。複数の画面から共通に使われるクラスは､インターフェースとして外に切り出されるので､再利用性の悪化あるいはロジックの分散を防ぐことができます。