プログラムを作る順序

＃昔を懐かしみつつ考えてるコーナー（ｗ
ある業務システムを作っていると仮定して、プログラムを作るときは業務の流れに沿って作るのが良いのか、それとも共通部分を括りだして・・・って方法が良いのか
個人的には業務の流れに沿って作るのが好きかなぁ〜
＃最初に作られるのはログイン画面、次がメニュー（笑）
メニューを作ってからが問題で業務の流れに沿って作ろうとして、ぺーぺープログラマ時代には業務の流れなんて書いてる資料見た事無いから（作られてなかった悪寒）業務の流れの代わりにデータの流れに沿って作ってたなぁ〜割と業務の流れと同じだったのは業務の流れがデータの流れとよく似てるから？
って事はドメインモデルの面倒だなぁって思ってる所は業務の流れを無視してドメインモデルを考えないと作れないところか・・・逆に言えば「ドメインモデルを作るために必要な情報はこれとこれとこれ、手順はこう」って誰かが言い切ってそれに納得すればそっちに移るんだろうなぁ〜
で〜（もしやここからが本題？）ハマチを使うような場合は本当の意味の業務フローと上に出てきた業務の流れの差が出てくる。ここがインピーダンスミスマッチって事になるんだ〜上に出てくる業務の流れって言うのは大体ユーザ毎の画面遷移をベースにしてる。だから、業務フロー上複数のユーザが絡むところで、場合によっては別のプログラマと情報の連携が必要
ここを補完するためにハマチがあったとして、XPDLファイルの修正とかどうするのかなぁ〜と考えて・・・
業務フローベースでプログラムを作っていき、メニューと後から組み合わせる。こうする事でインピーダンスミスマッチが発生しにくい構造になる予感。
って事は「ハマチを使った開発では作業者の作業単位としてはXPDLファイルのProcessを基準にする」ということになるのかなぁ〜
ってことは作業単位別にダミーのログイン＆メニュー画面が必要になるかも〜逆に言えば業務フロートレース画面って事でXX業務処理画面みたいな感じ？XPDLのイメージを貼り付けてクリッカブルマップで・・・え？コストかかりすぎかなぁ〜面白いアイデアだと思ったんだけど（爆）
っていうかクリッカブルマップなメニュー画面ってどうよ！個人的には結構好きだったりするけど（笑）クリッカブルマップなメニュー画面だとそれを使う人がどういう仕事の流れなのか明確に判るから良いと思うけどなぁ〜