次のページDIxAOPコンテナとシステム構築DI(依存性の注入)についての解説を行ってきましたが、ではDIxAOPコンテナが提供する依存性の注入はどのようなシステムを構築する時に利用すればよいでしょうか。DIxAOPコンテナが解決する依存性の注入は、ステートレスつまり値を持たないオブジェクトをつなぐのに向いています。このようなステートレスなオブジェクトを利用した設計パターンをトランザクションスクリプト(図4)といいDIxAOPコンテナはトランザクションスクリプトを実現するのに向いています。図4:トランザクションスクリプト(画像をクリックすると別ウィンドウに拡大図を表示します)トランザクションスクリプトで扱うドメインオブジェクトは、振る舞いを持たないシンドメイン(やせたドメイン)です。Object)やValueObjectなどと呼びます。このように見ていくと、ステートレスな制御処理とDBの操作を行うオブジェクトで構成されるWebアプリケーションは、トランザクションスクリプトで設計され、DIxAOPコンテナで実装することが向いているといえるでしょう。トランザクションスクリプトに対し、値と振る舞いを持ったコンポーネントがメッセージを交換し合うようなシステムの設計パターンをドメインモデル(図5)といいます。図5:ドメインモデルドメインモデルでドメインオブジェクトが持っている値をセットすることにDIxAOPコンテナは向いていません。DIxAOPコンテナはオブジェクトの作成時にセットすべき値を取得することができないからです(セットすべき値はテーブルに格納されています)。振る舞いをもったドメインに関してもDIxAOPコンテナで管理できるように考えている人たちもいますので、今後はドメインモデルの構築にもDIxAOPコンテナが向いているという時代が来ることも考えられます。インターフェースベースの設計DIxAOPコンテナの仕組みと適用ドメインについては、ここまでで理解していただけたかと思います。次にDIxAOPコンテナが多くの開発者に注目され利用されている大きな理由の1つであるインターフェースベースの設計について解説します。DIxAOPコンテナは原則として、具象クラスではなくインターフェースを利用してコンポーネント間の依存性を解決します。これによりWebアプリケーションの構築にDIxAOPコンテナを利用すると、レイヤー間にまたがるコンポーネント同士のメッセージ交換を直接行う(図6)のではなく、インターフェースを介して行うインターフェースベースの設計(図7)が促進されます。これによりAADL3の必須要素であるコンポーネント間の結合度を疎にすることが容易に実現できるようになります。図6:コンポーネント同士のメッセージ交換を直接行う場合(画像をクリックすると別ウィンドウに拡大図を表示します)図7:コンポーネント同士のメッセージ交換をインターフェースを介して行う場合(画像をクリックすると別ウィンドウに拡大図を表示します)DIxAOPコンテナを利用したインターフェースベースの設計でコンポーネント間の疎結合を実現できると表6のような利点があります。実装クラス同士の依存度が下がるため、後からロジックを変更してもその影響範囲を極小化できます。品質の向上モックを使って簡単にテストできるようになるためテスタビリティが向上します。使いたい機能の実装ができあがってなくても実装・テストを行えるため並行して作業できるようになります。再利用性の向上コンポーネントは通常のJavaのクラス(POJO)であり特定のAPI(EJBなど)に依存しないので再利用できる機会が増えます。裕一XMLの技術開発やCORBA、EJBを使用したシステム開発などを経て、現在はアジャイル開発プロセスの導入から工学的なソフトウエアプロセスの策定、オープンソースプロダクトに関するコンサルタント、アーキテクトとして常に第一線で活躍。現場で使えるリファクタリング(ソフトバンク)」、「Spring入門(技術評論社)」。鉄鋼系SIerを経て現職に。現在はオープンソースプロダクトに関するコンサティング、開発支援、教育を行うチームに所属。日々、新たな技術をどのように生かしていくかを考える毎日。現在の注目対象はSeasar2とMaven。