アスペクト指向の「横断的関心事」って、オブジェクトとして、独立させてはじくべきで、そうすると、わざわざ、この「横断的関心事」をもとに論理を展開させるのって・・・って、思っていたけど、意味的共通化とか、形式的共通化とか、書いていたとき、ふと、「あ、そうか、必要だ ^^;）」と気づいたので、メモメモ・・・（っていうことで、アスペクト指向の専門の人から見ると、的をはずしてるかもしれないが・・・）
■業務の共通化は、オブジェクトレベルで行うべきだが、
これは、要求仕様レベルである。
たしかに、業務部分で共通処理があるなら、その処理を切り出し、オブジェクトを作るべきだといえる。ただ、これは、「業務の共通化」の話なので、主に要求仕様、せいぜい、外部設計レベルまでの話である。
内部詳細設計の段階では、詳細化されているので、もはや業務の共通部分は、見えなくなっている。
■ところが、実装レベルで共通化しないといけないことがある。
ところが、実装レベルでも、共通化すべき処理がある。
データ入出力とか、テスト用処理とかなどなど・・・
とくに、要求仕様→外部設計の流れは、機能要件に関しては考慮するが、非機能要件に関しては、吟味されない（できない。実装方法（ＲＤＢとかマシンとか言語とか）が決まらなければ、何秒以内に返ってくるかなど、分かるわけがない）。なので、非機能要件のようなセキュリティ、外部入出力の高速化などなど・・・
■実装の共通化はフレームワークでやるはずだけど・・
たしかに、その部分の共通化はフレームワークがやるはずだけど、フレームワークでは、すべてをカバーしきれない。たとえば、Strutsで、画面データを取ってくる部分までの部分の面倒は見れるが、その画面データをログに書き出したりとか、そんな細かいことはしない。
それは、フレームワークの手落ちではない。フレームワークでこまかいことをやると、処理が重くなる上、設定が複雑になるどちらかといえば、フレームワークは、あんまり仕事しないほうがいい。
なので、プロジェクトレベルで見ると、フレームワークによる共通化だけでは不十分となる。
そこで、プロジェクトごとに共通化するところが出てくる。
■実装レベルでの共通化で、コーディング時に気づくと・・・
このプロジェクトごとの共通化だが、外部設計でフレームワークを決定するときに気づけばいいが、実際、コーディングして、さらに実機を動かしてみないと分からない場合がある（処理スピードがおそいので、効率化する場合など）。
このとき、共通化部分＝横断的関心事を直すため、オブジェクトを作るとなると、外部設計にまで戻ることになる（実装の共通化はフレームワークにかかわることなので、外部設計）。
ところが、外部設計をいじると、コストがかかる（上流を修正するほど、それ以降（下流）をすべて修正・見直しすることになるので、コストがかかる）。
そこで、実装レベルの共通化において、横断的関心事の対応をする手法が必要になる。
■で、アジャイルの場合
アジャイルだと、実装だけでなく、要求仕様なども動きながら行うため、意味的共通化が（全体を見渡すことが出来ないので）取れないことがある。その場合には、実装レベルだけでなく、意味的なレベルにおいても、横断的関心事を切り出す必要がある可能性もある。
アクセス
トータル
ランキング
