コンポーネント設計書

インターフェース設計書で、外部から呼ばれるメソッドとコンポーネント内からしか呼ばれないメソッドが同じように記述されるのは、混乱を招くようなので、コンポーネント設計書と名前を変え、バウンダリから呼び出されるメソッドには、印をつけることにしたいと思います。
実装上は、バウンダリから呼び出されるメソッドは、インターフェースになり、コンポーネント内からしか呼び出されないメソッドは、実装クラスのpublicメソッドになります。
内部からしか呼び出されないのに、実装クラスのpublicメソッドにするのは、テストをしやすくするためです。別にprivateメソッドでもリフレクションを使って呼び出せますが、コンポーネントを使う方は、インターフェースしか見ないので、特にpublicでも問題ないと思います。


前の設計書では、メソッドごとにどのインターセプタ（アスペクト）を使うのか、指定するようになっていたのですが、内部設計者には、難しすぎるようです。そもそもAOPを理解できてないので。
そのため、設計書にインタセプタを指定させるのをやめ、業務ロジック層のコンポーネントには、基本的にdiconファイルでj2ee.requiredのインターセプタを指定するってルールにした方が堅いかなと思ってます。


問題は、メソッドごとに記述する事後条件です。この前レビューしてみたんですが、悲惨なものです。これは、設計者のスキルが問題ではなく、事後条件はこうやって書くんだよという私の指針が足りないのです。
くーすは、というより私は、各開発者のスキルをまったくあてにしていません。ドライに聞こえるかもしれませんが、現実のプロジェクトを乗り切るには、そう考えざるを得ないのです。そして、どんな人でも一定の品質のものを作り上げるための仕組みを考えるのです。


メソッドのロジックを考えるのではなく、事後条件を先に考えるというのは、契約による設計というより、TDDに近い気がします。どちらにしても開発者はこのような手法に慣れていません。指針をしっかり出す必要があります。
くーすの場合、コンポーネントはステートレスなので、事後条件は、

• こんな引数なら戻り値はこうなる。
• こんな引数なら引数はこう更新される。
• こんな引数ならこのメソッドが呼びだされる。
• こんな引数ならこの例外が発生する。

のように記述します。また、テストケースを洗い出すのに、

• 本来しなければならないこと。
• 〜ならば〜すること。
• 例外

を念頭におくと良いでしょう。
「〜ならば〜すること」は、注意が必要です。「〜すること」を別のメソッドに切り出して、「〜ならばこのメソッドが呼び出されること」という事後条件にしましょう。
「本来しなければならないこと」が複数ある場合も、「本来しなければならないこと」を別メソッドに切り出します。