UPDATEがシステムを複雑にする？ イミュータブルデータモデルのすすめ

PHPカンファレンス新潟2025登壇資料

Transcript

1. UPDATEがシステムを 複雑にする？ イミュータブルデータモデルの すすめ PHPカンファレンス新潟2025 akshimo
2. • akshimo(あくしも) • 2021年〜新潟に移住 • フリーランス • 初登壇！ • おすすめのラーメン：東横
3. • 学生もわかる内容に • 学習・設計・仕事など何かのキッカケにして欲しい 本日のコンセプト
4. • イミュータブルデータモデルの概要 • イミュータブルデータモデルを使った実例 • イベント駆動と合わせたPHP & Laravelへの適用 本日のお品書き
5. • イミュータブルデータモデルの概要 • イミュータブルデータモデルを使った実例 • イベント駆動と合わせたPHP & Laravelへの適用 イミュータブルデータモデルの 基本と例を話します
6. • イミュータブルデータモデルの概要 • イミュータブルデータモデルを使った実例 • イベント駆動と合わせたPHP & Laravelへの適用 ちょっとひとスパイス！ もう一歩踏み込んだ使い方のご提案
7. イミュータブルデータモデルの概要
8. Yoshitaka Kawashimaさんが考案したモデリング手法。 データの更新に注目し、イミュータブル=更新されないモデルを設計し ていくことで複雑さに立ち向かうもの。 イミュータブルデータモデル https://scrapbox.io/kawasima/イミュータブルデータモデル イミュータブルデータモデル
9. イミュータブル データモデル
10. イミュータブル データモデル
11. Immutable=不変
12. Immutable=不変 => UPDATEをしない
13. Immutable=不変 => UPDATEをしない UPDATEすると複雑になるから なくしてこうぜ！
14. • ロストアップデート？ • ロック？ • ミスって変にデータを書き換えてしまったら？ UPDATEは不整合を起こしやすい
15. • わかりやすく、高度な専門知識を必要としない • モデリングのズレを一定解消できる • シンプルな設計ができる この辺が良いなと思ってます！
16. UPDATEをしないとか そんなの無理でしょー！
17. 全くUPDATEしないことも可能だけど 現実的でないことも多い！ できるだけ UPDATEを減らすようにしてみよう！ UPDATEをしないとか そんなの無理でしょー！
18. • 事業活動のヒト • 業務の関心のモノ • ユーザー、担当者、商品、店舗... データの種類 リソース • 過去に起きたコト • 注文、予約、キャンセル... イベント
19. • 事業活動のヒト • 業務の関心のモノ • ユーザー、担当者、商品、店舗... データの種類 リソース • 過去に起きたコト • 注文、予約、キャンセル... イベント UPDATEして OK！
20. • 事業活動のヒト • 業務の関心のモノ • ユーザー、担当者、商品、店舗... データの種類 リソース • 過去に起きたコト • 注文、予約、キャンセル... イベント UPDATEして OK！ UPDATEは NG！
21. • 事業活動のヒト • 業務の関心のモノ • ユーザー、担当者、商品、店舗... データの種類 リソース • 過去に起きたコト • 注文、予約、キャンセル... イベント UPDATEして OK！ UPDATEは NG！ “過去に起きたこと ”が 更新されるわけないしな …
22. “起きたコト ”が変更されることはない 起きたコト 金額 ユーザーID 日時 入金 3,000円 1 2024/11/21 10:00 入金 4,000円 1 2024/11/21 10:30 出金 6,000円 1 2024/11/21 11:00 入金 2,000円 1 2024/11/21 11:30
23. “起きたコト ”から今の状態を計算できる 起きたコト 金額 ユーザー ID 日時 入金 3,000円 1 2024/11/21 10:00 入金 4,000円 1 2024/11/21 10:30 出金 6,000円 1 2024/11/21 11:00 入金 2,000円 1 2024/11/21 11:30 残高 3,000円
24. イチイチ計算するのは辛いので 計算した結果（リソース）を保存しておく
25. イミュータブルデータモデル を使った実例
26. ECサイトの荷物管理の例
27. 実際にあったモデル（に近いもの）
28. 実際にあったモデル（に近いもの） いろんな状態があって 複雑…
29. 日時属性に注目する
30. 日時属性に注目する
31. 日時属性に注目する
32. 日時属性に注目する
33. 日時属性に注目する
34. 日時属性に注目する
35. 日時属性に注目する 未来日が入るであろう 配送予定日は除く！
36. リソースとイベントに分ける リソース イベント
37. 勝ったぜ！完！！
38. 勝ったぜ！完！！ んなわけない！
39. 日時属性に注目する UPDATEが発生
40. 1つのイベントには 1つの日時属性のみ
41. 1つのイベントには 1つの日時属性のみ
42. 1つのイベントには 1つの日時属性のみ
43. 1つのイベントには 1つの日時属性のみ
44. イベントへの UPDATEはなくなった！
45. 勝ったぜ！完！！
46. 勝ったぜ！完！！ 本当に？
47. 隠れた日時属性を見つけ出す
48. 更新日時を保存したい状況はない？
49. 更新日時を保存したい状況はない？
50. 2025年 5月31日 お客様からお問い合わせあり。 住所に入力不備があったとのことなので、荷物番号XXXの配送先住所を変更 した。 運用でよく見るメモ
51. 隠れた日時属性を見つけ出す
52. さらにnullをなくしていく nullは10億ドルの損失
53. nullをなくす
54. nullをなくす
55. nullをなくす
56. どうすれば nullをなくせる？
57. どうすれば nullをなくせる？ 交差テーブルを使おう！
58. 交差テーブルを使おう！
59. 交差テーブルを使おう！
60. 1. エンティティを抽出する 2. エンティティを分類する 3. イベントエンティティには1つの日時属性しかもたないようにする 4. リソースに隠されたイベントを抽出する 5. 非依存リレーションシップを交差エンティティにする イミュータブルデータモデルの手順 Kawashima 『イミュータブルデータモデル』 https://scrapbox.io/kawasima/イミュータブルデータモデル
61. イベント駆動と合わせた PHP & Laravelへの適用
62. The biggest outcome of the summit was recognizing that when people talk about “events”, they actually mean some quite different things. Martin Fowler 「What do you mean by “Event-Driven”?」 https://martinfowler.com/articles/201701-event-driven.html イベント is 何
63. LaravelにはEvent機能がある php artisan make:event PodcastProcessed php artisan make:listener SendPodcastNotification --event=PodcastProcessed https://laravel.com/docs/12.x/events
64. LaravelにはEvent機能がある class SendPodcastNotification { public function handle(PodcastProcessed $event): void { // ... } } https://laravel.com/docs/12.x/events
65. LaravelにはEvent機能がある class SendPodcastNotification { public function handle(PodcastProcessed $event): void { // ... } } https://laravel.com/docs/12.x/events Listenerクラス
66. LaravelにはEvent機能がある class SendPodcastNotification { public function handle(PodcastProcessed $event): void { // ... } } https://laravel.com/docs/12.x/events 引数で発行された イベントを受け取る
67. LaravelにはEvent機能がある class SendPodcastNotification { public function handle(PodcastProcessed $event): void { // ... } } https://laravel.com/docs/12.x/events やりたい 処理を書く
68. LaravelにはEvent機能がある class SendPodcastNotification { public function handle(PodcastProcessed $event): void { // ... } } https://laravel.com/docs/12.x/events キューとかで動くが 同期的にも動く
69. $dispatchesEvents
70. $dispatchesEvents class User extends Authenticatable { protected $dispatchesEvents = [ 'saved' => UserSaved::class, 'deleted' => UserDeleted::class, ]; } https://laravel.com/docs/12.x/eloquent
71. $dispatchesEvents class User extends Authenticatable { protected $dispatchesEvents = [ 'saved' => UserSaved::class, 'deleted' => UserDeleted::class, ]; } https://laravel.com/docs/12.x/eloquent Saveされたら UserSavedイベントを 発行
72. もうお分かりですかね？
73. ピッキングイベントが createされたらイベント発行 class Picking extends Model { protected $dispatchesEvents = [ 'created' => PickingCreated::class, ]; }
74. Listenerで発行されたイベントについて処理 class IssueInvoice { public function handle(PickingCreated $event): void { // ... } }
75. これであなたも明日からイベント駆動！
76. こんなシステムがあったとする 受注サービス 引当サービス 決済サービス 荷物作成 サービス call call call
77. イベントを使おう！ 受注サービス 引当サービス 決済サービス 荷物作成 サービス Order Created pub sub sub sub
78. • 受注サービスはイベントを発行するだけ(publish) • 呼び出されていたサービスはイベントを購読するだけ(subscribe) • イベント発行後、どんなサービスが実行されるか受注サービスは知らない イベントを使うと …
79. 👏 一旦本日のお品書きはこれで終了！
80. 蛇足（ただし長い）
81. ソフトウェアの開発ってなんで 大変なんでしょうか？
82. • ビジネス要求が遅いから(Late) ※Latestで最新という意味であることに注意 • 逆に言うと、最初からビジネス要求が完全固定されていて、 変更されることも絶対にないなら開発ってすごい楽だよね 個人的Answer
83. 1. プロジェクトの開始時点にすべての要求を集めることは できない 2. 集めたところで、要求はどれも必ずといっていいほど変 わる 3. やるべきことはいつだって、与えられた時間と賃金より 多い Jonathan Rasmusson 『アジャイルサムライ』
84. ソフトウェアを書き始める時、我々は対象 を十分に理解しているわけではない。 高度に生産的なチームは、自分たちの知識 を意識的に育てて、継続的学習を実践す る。 Eric Evans『ドメイン駆動設計』
85. 架橋工事がプログラミングのようなものだとすると、橋の 途中で岸がさらに50メートル先になってしまった、といった 具合です。 (中略)私たちが作成するソフトウェアはユーザ要件に柔軟 に適応し、進化するように設計されています。 Sam Newman『マイクロサービスアーキテクチャ』
86. 受注サービス 引当サービス 決済サービス 荷物作成 サービス Order Created pub sub sub sub
87. 受注サービス 引当サービス 決済サービス 荷物作成 サービス Message
88. Object Object Object Object Message
89. Object Object Object Message Message そうだね！ Smalltalkだね！ Message
90. • イベントドリブンなアーキテクチャとアラン・ケイの メッセージベースのオブジェクト指向は似ている気がする？ • キーワードは「遅延束縛」
91. The Japanese have a small word - ma - for "that which is in between" - perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. 日本語には「間」という言葉がある。おそらく最も近い英語は「interstitial」だろう。 偉大で成長可能なシステムを作る上で重要なのは、モジュールの内部特性や動 作よりも、モジュールがどのようにコミュニケーションをとるかを設計することだ。 (意訳) Alan C.Kay http://wiki.c2.com/?AlanKayOnMessaging
92. 受注サービス 引当サービス 決済サービス 荷物作成 サービス Order Created pub sub sub sub こいつが鍵って…コト！？
93. • メッセージを受信したオブジェクトが何をするかは受信側次第。 (送信側は預かり知らぬ) • つまり、意思決定や解釈(束縛)を極力遅くしている =>遅延束縛 • しかも、コード実行中にプログラムを書き換え、メッセージの解釈を変更で きる メッセージベースオブジェクト指向
94. • イベントを購読したサービスが何をするかは購読側次第。 (発行側は預かり知らぬ) • つまり、意思決定や解釈(束縛)を極力遅くしている =>遅延束縛 イベント駆動
95. ビジネス要求は遅い (Late) 故に、システムの意思決定も 遅くできるような構造を採用する => 遅延束縛(LateBinding)する
96. • 間=メッセージ=イベント • これを要素間でやり取りすることにより、意思決定を極力遅延 • 逆の言い方をすれば「最初から全てを知っている必要がない」 => 改変の容易さに繋がる => アジャイル的な考え方
97. ご清聴 ありがとうございました！ Ask The Speakerお待ちしてます！