業務ロジッククラスの粒度

これまで、業務ロジッククラスは、バウンダリ(画面)ごとに作成することになっていましたが、業務フローごとに作成する方が良いかなと思っています。業務フローとは、関連する幾つかのバウンダリで構成されるものです。
1つめの理由は、画面は、プレゼンテーションのフレームワークによって、構成が変わる場合があるので、それに業務ロジッククラスが影響を受けたくないということです。私は、Flex(Flash)やJSP(HTML)ベースのどちらでも開発するので、余計にそう思うのかも知れません。
2つ目の理由は、複数の画面で共通に用いられるメソッドの抽出が、より簡単に確実におこなえるようになることです。複数のクラスに分かれているものから、共通なメソッドを抽出するよりは、1つのクラスから抽出する方が簡単です。業務ロジックの設計の担当者も、業務フローごとに専任で割り当てられますからより確実におこなえるでしょう。
業務フローをまたがって共通に用いられるロジックは、これまでどおり補助ロジッククラスに抽出します。でも、補助ロジッククラスは、ほとんど見つからないでしょう。複数の業務フローで共通に使われるようなロジックはあまりないからです。そうすると、コンポーネント同士のコラボレーションもバウンダリ・業務ロジック・Daoの3者で行われることがほとんどとなり、シンプルになります。以前のやり方だと、補助ロジックが見つかった場合、シーケンス図に登場人物を増やさなければならないので、結構書き換えが大変だったのですが、新しいやり方だと、メソッドの呼び出し方が変わるだけなので、変更も容易です。