イミュータブルデータモデルの極意
•
30 likes•26,765 views
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
![イベント自体が親子構造をもつケース
{
“注文ID”: 1,
“注文日時”:”2021-10-10T04:50:40”,
“注文者”: {
“ID”: 3
},
“注文明細”: [
{
“注文明細ID”: 1,
”商品ID”: 8
“数量”: 5,
“単価”: 100
}
]
}
RDBのテーブルへの実装を考えなければ、こういう
構造を作って、「明細はイベントだっけ?」とか疑問
を持たないはず。
注文明細ID
商品ID
数量
単価
注文明細
注文ID
注文日時
注文者ID
注文
ひっくるめてイベント](https://image.slidesharecdn.com/masteringimuutabledatamodeling-211124093141/85/-20-320.jpg)
イミュータブルデータモデルの極意
- 2. Division into cases aを実数とする。xについての方程式 ax = 1 を解け。 a ≠ 0のとき: x = 1 / a a = 0 のとき: 解なし
- 5. Dataの場合分け
- 6. Data / Inform / Information Inform: “to convey knowledge via facts (事実によって知識を伝える)” Data (Factの集合) Information 選択・加工して知識を取り出す Value of Values (Rich Hickey) 業務システム構築におけるデータモデリング (和田省二)
- 7. Dataを場合分けする Event (コト) Resource (モノ) 日時属性をもつ 日時属性をもたない 非対称性 対称性 ある一時点 ライフサイクルがある 一時点の事実の記録なので、属性は変わる ことはない。 ライフサイクルにともない属性が変化して いくこともある。 属性が変化しても同じモノであることを示 すためIdentityが必要。 データは大まかに2種類に分別できる。
- 8. リソースとイベントの関係 会員削除 イベント 会員登録 イベント 会員 (会員ID = 1) 会員変更 イベント イベントによってリソースが生成・更新・削除される 会員変更 イベント
- 12. イベント-リソースの関連 When 時期 Where 場所 Who 主体 With Whom 相手 Whom 関係者 What 対象 Why 理由 How 手段 How many 数量 How much 金額 注文 (Order) 顧客 販売員 販路 商品 注文明細 (Order Line) 数量 単価 Event Resource イベントの7W3Hがリソースと関連を持つ
- 13. リソース-リソースの関連 依存関係があるか? ライフサイクルを同じくするかどうか? で場合分け Resource Resource 都道府県 国 部屋 ホテル 親子関係があって、親が存在なしでは 子が存在し得ない 部門 ユーザ リソースは非依存でどちらが先に作られ ても構わない 社員 電子書籍 所属 購読
- 19. 社員ID 氏名 社員ID 退職社員 現役社員 社員ID 社員区分 社員 社員区分= 現役 | 退職 リソースのサブタイプの場合は「区分」によって分類するとよい。 ※イベントのサブタイプは後述します
- 20. イベント自体が親子構造をもつケース { “注文ID”: 1, “注文日時”:”2021-10-10T04:50:40”, “注文者”: { “ID”: 3 }, “注文明細”: [ { “注文明細ID”: 1, ”商品ID”: 8 “数量”: 5, “単価”: 100 } ] } RDBのテーブルへの実装を考えなければ、こういう 構造を作って、「明細はイベントだっけ?」とか疑問 を持たないはず。 注文明細ID 商品ID 数量 単価 注文明細 注文ID 注文日時 注文者ID 注文 ひっくるめてイベント
- 23. アクティビティ日時 入会アクティビティ 入会アクティビティID 入会ID 入会ステータス 最終アクティビティ日時 入会 氏名 社名 … 入会アクティビティID 審査者ID … 入会アクティビティID 到着予定日 … 入会アクティビティID 入会申込 審査 会員証発行 免許証番号 確認者ID … 入会アクティビティID 免許証登録 入会ステータス= 入会申込| 審査 | 会員証発行| 免許証登録
- 24. リソース同士の関連付けのイベント 部門 社員 所属 所属の関連を作るのに、「配属」イベントがありそれを記録したい 部門 社員 所属 配属 リソースの関連とそれに関するイベントとは別で識別しよう
- 27. どのイベントを記録として残すか? これ自体が、業務設計であり、システム設計である。 ● リソースの発生・変更・消滅するところにはイベントがある → 変更履歴 ● イベント発生からまた次のイベントが生み出されることがある → 注文→請求→支払→出荷 などの一連の業務フローイベント ● 非依存のリソース同士が関連付け/解消されるところにはイベントがある。 → 予約、注文などの業務イベント ; 配属や割当などの操作履歴