なにかの設計方法
業務に使えるシステムを作るときの設計方法
最初に決めるもの
- 情報の塊
- 情報の状態遷移
- 権限とか役割
情報の塊とは
A4用紙1枚に普通に出力出来る程度の情報の塊
業務を知ってる人が普通に扱う情報をまとめた程度の物
情報の状態遷移とは
情報が登録されて無用になるまでの状態遷移
〜〜が終わった状態と表現出来るのが大事（省略して「〜〜済み」ってよくやる
状態遷移の間の線の部分が画面とかで言うActionに相当するもの
〜〜の部分になにかのprefixが入ってる場合は状態数が多すぎるので分割
普通に7つを超えると状態数は多いなって感じ
権限とか役割とは
大抵は組織構造そのまま、たま〜に例外があるのでそれを追加する感じ
状態遷移を起こせる権限とか、情報の塊を見れる権限とかそんなのがある
次に決めるもの
最初に決めるものを決めてると勝手に出てくるものも多々ある
- 入力チェック
- 計算ルール
- 状態表現ルール
入力チェックとは
状態遷移のActionとセットだったり、特定の状態とセットの入力チェック
情報の塊にガッツリ紐付くことはあんまりない
計算ルールとは
計算式とかそういうの
業務を知ってる人が少なくとも定義場所は知っているはず
状態表現ルールとは
状態遷移と違って、情報の塊から状態を導出するときのルール
状態遷移が殆どない情報の塊に状態を表現するルールで状態遷移が存在することもある
ここまでで
ほぼシステムを作れる情報が集まったことになる
システムに落とし込む
- 本当に業務が回るのかをレビューする
- 表示専用の情報の塊を用意していく
- 情報の塊を正規化する
- Actionを細かく定義していく
本当に業務が回るのかをレビューする
業務の専門家を連れてきて、情報の過不足とか状態遷移の無理なところを探る
大抵はこの辺りで情報の不足とか状態遷移の不足とかたまーに発生するルールとかが見つかりやすい
表示専用の情報の塊を用意していく
レビューしていくと、どういう画面を表示して...みたいなのが結構出てくるので表示専用の情報の塊を別途用意する
情報の塊（複数）と状態からどんな感じの表示をしたいかで決める
単純に部分的に表示するだけとか、集計した結果を表示するとか多岐にわたる可能性がある
ここで完全に固めなくても良いけど、元の情報が無い限り表示専用の情報は作れないのもポイント
状態表現ルールもここにかなり絡んでくる（状態表現ルールはここでほぼ決まる）
情報の塊を正規化する
情報の塊が沢山出来ると思うので、RDB的に適切に分割していく
第3正規化くらいまでで十分
Actionを細かく定義していく
状態をチェックして、入力をチェックして、入力後のデータをチェックして、各種ルールを実行して次の状態に変更して...を定義していく
Discussion