http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.html

クラス分割のところだけしか読んでないけど、
なんかもう、支離滅裂なんでちょっと突っ込む。

また、開発メンバーと保守メンバーのスキルに依存することにもなるため、
プロジェクトやメンバーのバランスによって、どのような設計手法を取るのかを
見極める必要がある。

結局のところ、これは業務分析のの問題であって
クラス設計の範疇ではない気がする悪寒。
その辺がここでは全部「設計手法」とかいうものに持っていかれているわけですが、
では、この記事で書かれているクラス設計は何をよりどころにして読めばいいのだろうか。

そんなときには、1つの機能（＝たとえWebアプリで複数のページに
またがっていたとしても一連の作業を完了させるまでの一連の操作）に対して、
1つのビジネス・ロジック層のクラスを作ってみることをお勧めする。

だから、それやっちゃうとそこで作ったいい加減なクラスの粒度が,
これから作成されるシステムの全体のクラス設計の基調を支配し始めるから大変なことになるのよー

2,3人で一月ぐらいでアドホックに作れる小さいシステムなら、これでも出来なくはないけど、
後から増改築が繰り返される老舗温泉宿パターン(今作った)に陥るのは目に見えてる。

この方法で構築するなら、この後のセクションのメソッド分割で使われてる
メモ帳でのオブジェクト操作の書き出し見たいな奴ををシステムの対象とする
業務にわたって使うほうがいいと思う。
そんなに規模が大きくなけりゃ、２，３日頑張れば終わるよ。

あと、「発送準備を行う」とかいい加減に書かないで、
もちろん、各文章はSVOをちゃんと書いてnhe。

そうすりゃどこぞで見た「まず、テーブルを設計します」と真顔で言われた会社よりは多少はマシになりますかね。