Source
メモ
3.1 帳簿デザインの進め方
帳簿をデザインする3通りの方法：
- UI の設計を通じて帳簿をデザインする
- DB の設計を通じて帳簿をデザインする
- データモデルを用いて帳簿をデザインする
本書が提案するのはデータモデルを用いて帳簿をデザインする手法。
外部設計の外部 = ユーザーが関知する領域。データモデリングは外部設計に属する。一方、DB 設計は内部設計に属する。
所感
自分はドメインモデリングの文脈でやっているので完全に同じことを考えているわけではないと思うが、すでに自分が普段からやっていることに近い気がする。読んでいて違和感がなかった。
3.2 UI 設計だけでは帳簿をデザインできない
画面や帳票の設計はユースケースに依存する。一方で、帳簿の構造は業務の流れに依存せず、業務機能に従うようにデザインするのが良い。業務プロセス・ユースケースは、ターゲットとする顧客セグメントの変化や技術進歩によって比較的容易に変化しうるものだから。
「ユースケース」は「業務プロセス」の一部であり、ある担当者があるタイミングで実行する業務のくくり。
UI設計がそのまま帳簿デザインになりえないが、データモデリングのインプットとしては重要な情報になりうる。
所感
ここも大きく違和感はないが、たぶんきちんとは理解できていない気がするのでもっと具体の情報で理解していきたい。
2章で、SoA と SoM の比較では SoM は SoA に比べて不安定という話があった。今回は「業務プロセス・ユースケース」と「業務機能」を比べて、「業務プロセス・ユースケース」は「業務機能」に比べて不安定という話。
3.3 DB 設計には技術的関心事が混入する
データモデリングを DB 設計と異なる設計としている理由は、DBの技術的側面を考えずに帳簿デザインに関するユーザーの関心事に集中するため。
- ナチュラルキー：業務上で用いるキー
- サロゲートキー：システム内部で自動生成されてユーザーの目に触れないキー
コラム：サロゲートキー値の洗い替え
注意すべきは、サロゲートキーをシステム画面に露出させてはいけない
すごく理解はできるけど、ムズすぎるんだよなぁこれ..