Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
5分でわかる イミュータブル データモデル
Search
akshimo
November 22, 2024
2
230
5分でわかる イミュータブル データモデル
akshimo
November 22, 2024
Tweet
Share
More Decks by akshimo
See All by akshimo
新潟の勉強会を盛り上げたい!
shimomura
0
29
その設計、 本当に価値を生んでますか?
shimomura
3
220
私の推し技術(DERTA Gig #18)
shimomura
1
81
UPDATEがシステムを複雑にする? イミュータブルデータモデルのすすめ
shimomura
2
980
アラートの話 をしよう!
shimomura
0
89
serverless
shimomura
1
210
機械翻訳との付き合い方
shimomura
0
250
Featured
See All Featured
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.1k
Designing Powerful Visuals for Engaging Learning
tmiket
0
190
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
196
70k
How to build a perfect <img>
jonoalderson
0
4.8k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Building Adaptive Systems
keathley
44
2.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
74
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
760
Evolving SEO for Evolving Search Engines
ryanjones
0
77
Transcript
5分でわかる イミュータブル データモデル Niigata5分Tech #14
• akshimo(あくしも) ◦ X:@akshimo • 東京出身 ◦ 2021年〜新潟へ移住 • 無職
• 好きなもの ◦ アジャイル、スクラム ◦ DDD、BDD、イベント駆動 ◦ 物理学、哲学 ◦ ウイスキー、アブサン 自己紹介
イミュータブル データモデル とは?
Yoshitaka Kawashimaさんが考案したモデリング手法 。 データの更新に注目し、イミュータブル=更新されないモデルを設 計していくことで複雑さに立ち向かうもの。 プログラミングの文脈で語られるイミュータブルなモデル(return this;しないでreturn new…するやつ)とは別物です。 ※今回はKawashimaさん含め複数の方の書籍・記事などを混 ぜて話すので注意してください。参考文献の一読をオススメしま
す Immutable Data Model
イミュータブル データモデリング
イミュータブル データモデリング
永続化 関心 変更 アプローチ データモデリング 意識する 客観的な 事実・データ ゆるやか 部分から全体
ドメインモデリング 意識しない 意味と目的がある データの加工・判断 のロジック 頻繁 全体から部分
ちなみに ドメインモデルと データモデルのギャップを インピーダンスミスマッチと呼ぶが 今回はその話は割愛
イミュータブル データモデリング
更新が複雑さを生み出す CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑な ルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこと もあるが、システム、設計で複雑さを更に増さないようにしたい。 UPDATEに 着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、 まずデータモデルをそのように設計しておかなけれなならない。 Kawashima 『イミュータブルデータモデル』 https://scrapbox.io/kawasima/イミュータブルデータモデル
とはいえUPDATEを 全くしないことは 現実的ではない …
とはいえUPDATEを 全くしないことは 現実的ではない … =>UPDATEするモデルと しないモデルを分ける
DBに保存するもの リソース (ヒト・モノ) イベント (コト) • 事業活動の当事者 • 業務の関心の対象 •
UPDATE可能 • ユーザー、担当者、商品、店舗... • 過去に起きたこと • これから起こること(約束) • リソースの関係として出現 • UPDATE不可 • 注文、予約、キャンセル...
DBに保存するもの リソース (ヒト・モノ) イベント (コト) • 事業活動の当事者 • 業務の関心の対象 •
UPDATE可能 • ユーザー、担当者、商品、店舗... • 過去に起きたこと • これから起こること(約束) • リソースの関係として出現 • UPDATE不可 • 注文、予約、キャンセル... 重要!
起きたコトは変更されることはない 起きたコト 金額 ユーザー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
起きたコトから今の状態を計算できる 起きたコト 金額 ユーザー 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円
イチイチ計算は辛いので 計算した結果(リソース)を保存しておく
コトとモノはトランザクション整合性を もたなくても良い =>結果整合性
コトとモノはトランザクション整合性を もたなくても良い =>結果整合性 業務によっては数 ms~数日のタイムラグが あっても問題ない
コトとモノはトランザクション整合性を もたなくても良い =>結果整合性 業務によっては数 ms~数日のタイムラグが あっても問題ない ここからCQRSやイベントソーシングの 話にも発展していく
1. エンティティを抽出する 2. エンティティを分類する 3. イベントエンティティには1つの日時属性しかもたないようにす る 4. リソースに隠されたイベントを抽出する 5.
非依存リレーションシップを交差エンティティにする Kawashima 『イミュータブルデータモデル』 https://scrapbox.io/kawasima/イミュータブルデータモデル イミュータブルデータモデリングの手順
FAQ (よく尋ねられると思われる質問)
これはそのまま RDB設計にするの?
NO! RDBにはRDBの都合があるので、そのままRDBの設計にはしなくて 良いです。 むしろ、データモデリングはエンジニア以外にも理解できるものにす る必要があります。 具体的には、性能などの課題解決のために RDB設計は適宜最適化 します。 これはそのまま RDB設計にするの?
DDDのモデリングとは相反するもの?
NO! レイヤーが違うと自分は思っています。 両立は可能で、むしろ互いに補完するものかと思います。 DDDのモデリングとは相反するもの?
Kawashima 『イミュータブルデータモデル』 https://scrapbox.io/kawasima/イミュータブルデータモデル Kawashima 『WEB+DB PRESS Vol.130 実践データモデリング』 増田 亨
『現場で役立つシステム設計の原則』 参考文献
CREDITS: This presentation template was created by Slidesgo, and includes
icons by Flaticon, and infographics & images by Freepik Thanks! Do you have any questions? Please keep this slide for attribution