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.6k
技術負債とデータ構造
naQamura
January 25, 2024
Tweet
Share
More Decks by naQamura
See All by naQamura
想像力の隙間を埋める
na9amura
0
110
開発組織が情報発信の打席に立てる土台を作った一年を振り返る
na9amura
0
1.8k
アンラーニングを体験しよう
na9amura
2
380
MPA+CSRでMVPを作って継続的に拡張しよう BARフロントえんどう#1
na9amura
0
110
技術負債とソフトウェアアーキテクチャ
na9amura
0
160
Other Decks in Programming
See All in Programming
アプリの "かわいい" を支えるアニメーションツールRiveについて
uetyo
0
230
Swift Updates - Learn Languages 2025
koher
2
470
アルテニア コンサル/ITエンジニア向け 採用ピッチ資料
altenir
0
100
時間軸から考えるTerraformを使う理由と留意点
fufuhu
16
4.7k
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
3
290
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.8k
Go言語での実装を通して学ぶLLMファインチューニングの仕組み / fukuokago22-llm-peft
monochromegane
0
120
そのAPI、誰のため? Androidライブラリ設計における利用者目線の実践テクニック
mkeeda
2
280
Testing Trophyは叫ばない
toms74209200
0
860
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
210
Deep Dive into Kotlin Flow
jmatsu
1
320
テストカバレッジ100%を10年続けて得られた学びと品質
mottyzzz
2
590
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
246
12k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Six Lessons from altMBA
skipperchong
28
4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Side Projects
sachag
455
43k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
13k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
A Modern Web Designer's Workflow
chriscoyier
696
190k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Speed Design
sergeychernyshev
32
1.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
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