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
技術負債とデータ構造
Search
naQamura
January 25, 2024
Programming
1
1.3k
技術負債とデータ構造
naQamura
January 25, 2024
Tweet
Share
More Decks by naQamura
See All by naQamura
想像力の隙間を埋める
na9amura
0
77
開発組織が情報発信の打席に立てる土台を作った一年を振り返る
na9amura
0
1.2k
アンラーニングを体験しよう
na9amura
2
310
MPA+CSRでMVPを作って継続的に拡張しよう BARフロントえんどう#1
na9amura
0
38
技術負債とソフトウェアアーキテクチャ
na9amura
0
89
Other Decks in Programming
See All in Programming
ゲームボーイアドバンスでSwiftを動かそう
k_koheyi
0
500
dRuby 入門者によるあなたの身近にあるdRuby 入門
makicamel
4
340
The Future of Frontend i18n : Intl.MessageFormat
sajikix
1
2.4k
座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか?」
shiz
4
2.9k
マイグレーションコード自作して File-Based Routing に自動移行!! ~250 ページの歴史的経緯を添えて~
cut0
1
240
1人で挑むSwiftコンパイラ 〜型システム入門編〜
s_shimotori
0
310
『ドメイン駆動設計をはじめよう』中核の業務領域
masuda220
PRO
5
840
GoのIteratorに詳しくなってしまう
inatonix
1
170
eBPF Japan Meetup のご紹介
kentatada
0
140
Swift Concurrencyとレースコンディション
objectiveaudio
1
380
詳解UIWindow
natmark
3
2k
複雑さに立ち向かうための ソフトウェア開発入門
shiz
2
570
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
28
2.2k
Fashionably flexible responsive web design (full day workshop)
malarkey
400
65k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Unsuck your backbone
ammeep
667
57k
Statistics for Hackers
jakevdp
793
220k
RailsConf 2023
tenderlove
26
790
From Idea to $5000 a Month in 5 Months
shpigford
378
46k
Making Projects Easy
brettharned
113
5.8k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
165
48k
Gamification - CAS2011
davidbonilla
79
4.9k
In The Pink: A Labor of Love
frogandcode
139
22k
Designing the Hi-DPI Web
ddemaree
278
34k
Transcript
技術負債と データ構造 ハコベル株式会社 中村隆宏 TECHBREW IN 東京 〜技術的負債と共に歩むプロダクトの成長〜
所属:ハコベル株式会社 (旧 ラクスル株式会社ハコベル事業部) 役職:シニアアーキテクト 職歴:Paiza 、決済サービス、SI 系 経歴:熊本出身、文化人類学専攻 趣味:旅行、音楽、MMA
中村隆宏 (na9amura)
None
プロダクトラインナップ 取引階層のフラット化とドライバー の非稼働時間の有効活用 物流に関わる人たちを繋ぎ コミュニケーションを円滑化 AI 技術を活用し配送効率アップ、 業務の効率化、属人化解消
1.テーマ設定
Introduction ハコベルに入社して約6 年、ハコベル配車管理とハコベル 配車計画の2 プロダクトでローンチから運用・拡張に携わっ てきました。作ってしまった技術負債、予防すべく努力して いる部分、様々な技術負債との関わり方をしてきました。 今回はその中からデータ構造にまつわるものを紹介しま す。負債を抱えたくなかったと考えることが多く、予防しよ うと努力している部分です。それを身近なモデルに落とし込
んで紹介します。
2.サンプル
EC サイトを構築するとします。今回サンプルなので以下ような小さいス コープとします。 ユーザー情報を登録する 商品情報を登録する 商品を注文する ECサイトのデータ
ID name address 1 中村 熊本市西区… 2 … ... ID
name quantity 1 チョコレート 22 2 … … ID user_id item_id orders 1 1 1 1 2 … … … Users Items Orders Data structure ユーザー、商品などのマスタデータ 注文データなどのトランザクションデータ ID でリレーションを貼る ようなものが構成として思いつくのではないでしょうか
View Usersテ ーブルから 中村 熊本市西区 Itemsテ ーブルから チョコレート 24個 Order
1
完成!
本当に?
ID name address 1 中村 つくば市春日… 2 … ... ID
name quantity 1 チョコレート 22 2 … … ID user_id item_id orders 1 1 1 1 2 … … … Users Items Orders Update Records 例えばえばこいう場合 ユーザーが引っ越した 商品がリニューアルした
Updated View Usersテ ーブルから 中村 つくば市春日 Itemsテ ーブルから チョコレート 22個
Order 1
3.何が起きた?
事実の改変 過去に起きた事実はそれ以降の変更に連動しません。今回で言うと届け 先、商品個数は変わらない。ですがシステム、データ、画面上では変わっ てしまっています。
ユースケースの混在 登録ミスがあった場合にレコードを更新する 住所変更、商品リニューアルによりデータを追従させる この2 つのユースケースがありえる。どちらによるものかデータ上から区 別ができない。
データのライフサイクル Users, Items テーブルの カラム内のデータは業務で必要なのに先に消失している レコードは業務で使う単位より長生きしている つまりは、実務上はUsers, Items のライフサイクルとOrders のライフサイ
クルは異なる。しかしデータ構成上そうなっていないと言えます
4.どうしよう
ID name address 1 中村 つくば市春日… 2 … ... ID
name quantity 1 チョコレート 22 2 … … ID user_id item_id orders ship_to quantity 1 1 1 1 熊本市西区… 24 2 … … … … … Users Items Orders 1. Snapshot データの更新に追従しないデータをそのまま保 存する。データの量・性質によってはusers, items テーブルを丸々コピーしても良いかも。
ID name address 1 中村 熊本市西区… 2 … ... ID
name quantity 1 チョコレート 24 2 チョコレート 22 Users Items Orders 2. Domain Logic 変更不可なデータを更新させず、データを追加 する。バリデーションで防いでもいいし、デー タ更新UI を提供しないことで対応するなど(ル ールの永続性に問題はあるが) ID user_id item_id orders 1 1 2 1 2 … … …
ID name 1 中村 Users Orders 3. Immutable Datamodel データ構造でデータの不変性を担保する。データ取得
する際に必要な時点のデータを取得します。 今回の場合: WHRER orders.created > addressed.created ORDER BY addresses.created DESC LIMIT 1 ID user_id item_id orders created 1 1 2 1 2015/01/01 2 … … … ID user_id address created 1 1 熊本市西区… 2010/01/01 2 1 つくば市春日… 2020/01/01 Addresses
5.まとめ
「マスタデータ」とざっくりカテゴライズしているものの中には、実は複 数の性質が混在しています。 本当にUpdate されるべきもの 「テンプレート」「シード」のような性質のもの 今回のサンプルは身近で予想しやすい事例。しかしオペレーションが複 雑、ドメイン領域の理解が浅い場合このような性質が見えにくいです。 ドメインの観点
技術負債の中でもデータ構造にまつわるものは重要度が高いと私は考えて います。以下の観点から初期に整理しておくことを推奨します。 データ構造変更、マイグレーションは作業コスト、リスクが高い 最初のデータ構造で保持してないデータは復元できない 技術負債の観点
技術負債はネガティブな要素も多いですが、うまくトレードオフを考えつ つ借り入れることでプロダクトの成長を加速させられるメリットもありま す。しかし実際のお金と違い、返済しやすいもの、しにくいものがありま す。その性質を見極めて計画的に借り入れましょう! ご利用は 計画的に 全体まとめ
ドメイン知識理解、データ構造設計、ユー ザーバリューへの向き合いのバランスを高 いレベルで調和させたい人!募集中です!
THANK YOU