読者です 読者をやめる 読者になる 読者になる

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で実現できるかどうかを判断できると思います。

また、アーキテクチャ設計で、レイヤー設計をきちんと行っておくと、AOPの適用箇所も考えやすくなります。