Teeda Extension featuring Goya 〜内部設計【AOPの適用】〜
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト
AOPの適用は、自分でも何となくやってしまっているところがあり、設計手法として改めて考えてみると、説明が難しいところがあります。
今回は、自分なりの考えをまとめてみます。
AOPをどこに適用すれば良いのか？
「AOPとは何か？」って聞かれたら答えやすいのですが、「AOPをどこに適用すれば良いのか？」と聞かれると、答えるのが難しいですね・・・。
自分で設計していても、感覚的に決めてしまっているように思います。
AOPの例として、トランザクションやロギング処理が良く取り上げられるますが、それらはシステム全体としては、どのように位置づけられるのでしょうか？
システムとして、ユーザに適用する機能（core concern）とAOPで実現する機能（crosscutting concern）は、縦横のような関連を持ちます。
そこで、トランザクションやロギングの処理を考えてみると、共通項として得られるのは、
-
- レイヤー
- 業務に依存しない共通処理
ではないかと思います。
AOPの適用箇所について、いろいろと調べて見ましたが、僕が考えるAOPの適用ポリシーでも、似たようなことが書かれていました。
Seasar2では、便利なInterceptorが標準で多く提供されている（S2AOPで用意されているInterceptor）ため、独自で作成する機会はあまりないかもしれませんが、私の場合、上のような視点で適用箇所を見出しています。
AOPに対する危惧
AOPの解説などを見ていると、「機能をあとづけできます！」という記述を良く見かけます。
しかしながら、それって、AOPを「銀の弾」扱いしすぎているように思います。
たしかに、あとづけ「も」できますよ。
ただ、AOPは、適用箇所（JointPoint）なども限られます。S2やSpringなどのDIコンテナで、確実にAOPは利用しやすくなりましたが、やはりある程度設計しておかないと、後から適用できないことがわかって、全機能を修正する必要がでてきた、なんてことに陥る可能性があります。
少なくとも、適用するレイヤーと、そこで必要となるパラメータぐらいは決めておくと良いでしょう。
大抵は、それでAOPで実現できるかどうかを判断できると思います。
