Build on Strutsのアーキテクチャ考

StrutsはWebアプリケーション開発においてデファクトスタンダードの地位を確立した感がありますが、実際に大規模システムを開発してみると悩ましいのが「コンポーネントの粒度が細かすぎる」ことではないでしょうか。
よくある話として、ある機能を改修しようと思うと、struts-config.xmlを解析して、関連するJSPやAction/Formを一通りリストアップする必要があります。自分が作った機能でも面倒なのに、人が作った機能のメンテなんてことになると・・・。
こういう事態に対処するため、詳細設計書に関連するファイル一式を書いておく（もしくはコンポーネント図を付ける）ということをやりだすと、こんどはソースコードと書類の二重メンテが発生してさぁ大変、てなことになりがちです。
やはり根本的にこの問題に対処するならば、アーキテクチャを根本的に見直す必要があるでしょう。
コンポーネントの粒度をどうするかについては、三つのアプローチがあります。
(0)「遷移」を基本単位とする
ある一つのページ間遷移、すなわち「アクション」を基本単位とするアプローチです。生Strutsがこれに該当しますので、「アクション」毎にクラスを作成し、コンポーネント構成ファイル(struts-config.xml)によってコンポーネント間を疎結合します。疎結合による再利用の促進というメリットがある反面、コンポーネントの粒度が細かくなりすぎて取り扱いが煩雑になるというデメリットがあるのは既に述べたとおりです。
(1)「ページ」を基本単位とする
特定の「ページ」に関連するコンポーネントを基本単位とするアプローチです。モデル化の対象が「Webページ」ですから、コンポーネントは「コンテンツ（表示項目や入力項目）」と「アクション（リンクやボタンによって発生するイベントのハンドラ）」で構成されます。Webアプリケーションはページ単位で設計されることが自然なので、この粒度はかなり見通しが良いと思います。具体的な適用例としては、OzStrutsが挙げられます。
http://sourceforge.net/projects/optionzero/
JavaWorld2005年3月号のStruts特集で取り上げられていますので、興味のある方はそちらもどうぞ。
(2)「ページ遷移全体」を基本単位とする
全ての「ページ」と「遷移」、要するに1機能を基本単位とするアプローチです。コンポーネントの単位は「ページ遷移全体」(=ページフロー)となります。具体的な適用例としては、Apache BeehiveプロジェクトのPageFlowが挙げられます。
http://incubator.apache.org/beehive/
ちなみに、ページフローをGUIで編集したい方は、WebLogic Workshopを試してみてください。開発用途であればWebLogic Platformも含めて無償です。
http://www.beasys.co.jp/BeaPortal/application?namespace=BeaPortal&origin=index.jsp&event=link.evamenu&ID=1&VERSION_KEY=20
このアプローチの利点は、1機能を実現するために必要なロジックが全て集約されることにより、ロジック間でのデータの受け渡しなどが簡単に行えることです。