要件定義で概略的な登場人物を見つける。まぁ「社員」「顧客」「身分証明書」「○○申込書」
「○○申請書」「ポストオフィス」「メールボックス」「ホスト」「申請キュー」等がありがちなクラス
かな。この時点でシス管は LDAP だとか FireWall だとか考えてるし、ＤＢは論理設計考え
てるはず。次の設計でオブジェクトの挙動とＤＢの論理設計をまとめて、そして実装。

すげー簡単に書いたけど、途中にはＤＦＤもいるしネットワーク構成もいるし、ユースケース・
ステート図・クラス図・シーケンス図・テーブルアクセス順序・トランザクション分離・ハード
ウェア構成も書かなきゃいけないし結構大変。まぁ OO で機能モデルがかなり単純化され
るので、開発物の機能変更や仕様変更時の対応が早くなったな、というのがいつもやって
たサーバサイドの設計。最近は C/S やってた VB 会社や汎用機開発専門会社がこぞっ
て流れてきたから、再び「フロー」中心設計になりつつあるような気がする。

現実モデル持ち込むと、設計概念が簡単になる代わりに実装可能性とかパフォーマンスの
観点で設計にそこそこのスキルが必要。嫌う人もいるけどね、規模がでかく=人が多くなれ
ば概念が簡単になるメリットもでかい。「今の動き」に「その機能変更」を入れた場合の影響を、
お客さんはもとよりマネージャ、運用レベルの人に説明しやすい。出来ないのははっきり
逝って設計者のスキルだけ。