UMLモデリングの本質：モデリングの実践２（航空券の予約）での題材をモデリングする。
- 羽田や成田、新千歳は、空港という分類でまとめられる
- 実装的には(ややこしい)振る舞いがあれば継承構造、そうでなければEnum
- 誰が、いつ、どこから、どこへ行くのかがモデル化できれば良い
- 顧客をEntityとするかVOとするかは業務要件次第
- 顧客が自分でサイトから予約できるようにするのであればEntity、代理店のカウンターで予約するような形でよければVO
- 片道予約を複数管理すれば良い
- 受注と受注明細のような親子関係を作る
- 航空券予約の場合、出発日時でソートできるので、明細毎の順序管理は不要
- 空港と同じくグレードでカテゴリ化する
- 東京⇒北海道でエコノミー、北海道⇒東京でビジネスという可能性があるため、予約に紐付ける
- 空席予約のためには、各便と各座席を管理する必要がある
- どの座席に座るのかまで管理するため、座席もEntity化する
- たとえばコンサートでアリーナのスタンディング席を予約管理する場合は、キャパシティ人数のみ管理でよいためEntity化する必要はない
- 座席グレードは各座席のプロパティとして紐づく
- 予約Entityと便Entityはほぼ同じ意味と思われるので、便Entityに差し替える
- ただ厳密には同じ概念ではないため、一部の情報が損なわれる（予約日など）
- また便は経路を管理するための概念なので、それだけでは具体的な便が判別できない（何日発のJL999便なの？）
- 抽象的な便と旅程を紐付けるための予約Entityを中間クラスとして配置する
- 実際には「何日のXXX便」を特定するキーが業界には存在するのかもしれないが、現時点ではその知識はない
- 機種を管理することで指定機種の予約が出来る
- 便と座席を直接関連付けずに、サービスという抽象層を挟むことで、乗用以外の利用を管理する
- 同じ飛行時間帯に複数の予約はできない
- トランジットに一定の時間バッファを持つ
- などなど
-
データベース制約として実装する
-
メリット：強固な制約となる（データベースを直接操作されても大丈夫）
-
デメリット：強固過ぎる、INSERT制約にしか使えない（再利用性がない）
-
アプリ制約として実装する
-
メリット：自由度の高い制約が作成できる、制約の使い回しができる
-
デメリット：データベース自体に直接データ投入されるとモデルが不整合になる場合がある
- ユニーク制約など簡易な制約であれば、データベース・アプリの両方に設定しておく
- Entityのユニーク制約などは最低限かけておかないと、アプリ上でモデルが構成できなくなる
- 簡易な制約以外は原則ポリシーとしてクラス抽出する
- 制約は存在すると、さまざまな場面で適用しなければならないことが多い
- データ登録時の可否判断はもちろん、画面への表示時の制御、リストの抽出条件として、インポート機能の制御など、同じ制約を適用する必要がある
- クラス抽出することで単体テストが適用可能