パッケージ指向の設計

数十〜数百本のアプリケーションで構成された、比較的大規模の企業システムを開発するとして、出来たシステムを企業内の複数の拠点に展開することを考える。それぞれの拠点での仕事の内容は基本的には同じであり、拠点によって多少は扱う項目の種類が違う場合があるものとしよう。
提供されるシステムはまずは先行して、いずれかの拠点をターゲットに開発するとして、この最初のシステムをベースに、如何に工数を抑えて他の拠点にポーティングできるかを考えた場合、それぞれの層をどのように設計するのがベストだろう。

サーバサイドはUNIX系かWindows系か、はっきりしない為、Javaで提供するのを前提としてざっと考えてみたが

  • プレゼンテーション層


ビューにはJSP+ビューコンポジションorコンテンツテンプレート(TILESのようなフレームワーク)か、Tapestry等のテンプレートエンジンを使用することとし(現時点ではJSFは対象外) 、拠点間の多少の違いはビューで吸収する(個々に書換える)。ビューからビジネスロジックに渡す情報のために、DTO(Data Transfer Object)を用意することとするが、基本的にはビューから自動生成することとして、ビュー専用のBeanは作らないこととする。いわゆるDynaBeanのようなDTOだ。これだと個々の項目の型は静的に決まらないが、ビューに合わせて変更する必要が無く、融通が効く。

プレゼンテーション層から入ってくるDTOを入力情報として使用する。バリデーションに使用するルールは外だしにして、拠点毎に特殊ないわゆる"ローカルルール"を吸収できるようにしよう。このシステムは、拠点間で業務の差異があまり無いのが前提のため、ビジネスロジッククラス自体は、上手く設計すれば拠点共通のクラスとして定義できる可能性が高い。従って、ビジネスロジックは普通に業務からのトップダウンにより機能の切り分けでクラス設計を行なうが、拠点の項目の違いは考慮せず、項目の編集は拠点毎に書換える程度で充分か。

  • データアクセス層

拠点間による違いは項目の違い、表示するデータの有無、取得先の違いに現れる。従ってデータ取得の為にDAO用のインタフェースを起こしてデータアクセス層を隔離すると共に、項目の違いを透過に扱うためにDAOとマッピングされるSQLは外だし(テキストファイルorXML)にしてパラメタ化する。パラメタ化されたクエリは拠点毎にOn/Offできる切替えの為の句を拡張して、拠点間のSQLの違いを簡単に切替えられるように。DAOは実行されたクエリの結果から生成されることとし、Map等にマッピングすることで特定のBeanは生成しない。DTOと同様の抽象化だな。そうするとBeanには依存しないがSQLに書いた列名、つまりスキーマに依存する作りになるので、どこかで列名とDAOの項目名の紐づけをする仕組みを提供することで、スキーマの項目名を抽象化して、ロジック内で使うことができるだろう。

トータルではDIを導入し、コンポーネントとしてビジネスロジックレイヤのクラスをプラガブルにし、ログ採取のクラスや認証系のクラスをAOPでウィーブ、そこまでやれれば良いかな。

ざっと書いてみたが全てフレームワークレベルでできることであり、アプリケーション個々でどうこうする問題ではないような気がする。これ以上、アプリケーション上でも考慮できる、拠点間のシステムカスタマイズを楽にできる為の手法、技法は無いものだろうか。