アプリケーション開発の統一

ここに記載される内容は、世の中に蔓延するオブジェクト指向ベース業務アプリケーションフレームワークへのアンチテーゼでもあります。

アプリケーションフレームワークの提供するトランザクションのサーバ内レスポンスに満足していますか？

業務WEBアプリケーションとはいえ1時間当たり20万ページビューの要求はあるのです。全てのビューが動的なのがアプリケーションです。静的なページですら20万ページビューはかなりのトランザクションといわれます 。ハードのパワーでねじ伏せるといっても、トランザクションあたりの処理時間は可能な限り短く、サーバ内レスポンスは1msecたりとも無駄にしたくはありません。 「必要なものを提供する」、逆に言えば「不要なものは提供しない」がモットーです。

業務ロジックはPOJO ∗1 ですか？　社内他システムから呼び出し可能ですか？

社内システムに閉じたSOA ∗2 の鍵は業務ロジックの独立性です。POJOで作られた業務ロジックは社内他システムからの呼び出しを容易にします。

その業務ロジックは他社向けにカスタマイズする必要がありますか？

社内でのみ活用している間はアプリケーションテンプレートに従った構築で十分です。
しかし、フランチャイズにアプリケーションを展開したい、提携先にアプリケーションを提供したいといった場合、業務ロジックに個社案件というものを注入せざるを得ない場合が発生します。

このような場合は、DI(Dependency Injection) ∗3 、AOP(Aspect Oriented Programming) ∗4 によるリファクタリングを行います。
その場合、業務ロジックをPOJOで提供していることがアドバンテージとなります。
DIはコードのトレースやデバッグを困難にもします。しかし、開発時に決定されていなかった条件が入り込んで来た場合、プラグイン拡張を容易にしてくれるのがDIでありAOPです。

• ∗1 POJO(Plain Old Java Object)：特定のフレームワーク環境がなくても単体試験が可能なオブジェクト
• ∗2 SOA(Service Oriented Architecture)：サービスの組み合わせによってアプリケーションを構築する考え方。サービスにはオープンで標準的なアクセス方法をサポートすることが求められる。
• ∗3 DI(Dependency Injection)：コンポーネントの呼び出しをフレームワークに持たせる技術。インタフェースが同じであれば運用レベルで交換可能なコンポーネントを実装できる。
• ∗4 AOP(Aspect Oriented Programming)：様々な既存コンポーネントに変更を加えることなく、コンポーネント間共通の機能を追加する技術