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コードバトル必勝法
toshi0383
0
140
Appleの新しいプライバシー要件対応: ノーコードアプリ プラットフォームの実践事例
nao_randd
1
450
どうしてこうなった?から理解するActive Recordの関連の裏側
willnet
5
510
暴走のウホーレン 〜想いってのはvimrcにしないと伝わらないんだぜ〜 / iosdc_japan_2024
uhooi
1
240
Prompt Cachingは本当に効果的なのか検証してみた.pdf
ttnyt8701
0
250
仮想ファイルシステムを導入して開発環境のストレージ課題を解消する
segadevtech
2
390
メモリ最適化を究める!iOSアプリ開発における5つの重要なポイント
yhirakawa333
0
370
Some more adventure of Happy Eyeballs
coe401_
2
150
労務ドメインを快適に開発する方法 / How to Comfortably Develop in the Labor Domain
yuki21
1
250
Meet BrowserEngineKit
swiftty
0
190
Mergeable Libraryで 高速なアプリ起動を実現しよう!
giginet
PRO
1
1.8k
iOSの隠されたAPIを解明し、開発効率を向上させる方法/iOSDC24
noppefoxwolf
2
120
Featured
See All Featured
The Language of Interfaces
destraynor
153
23k
Ruby is Unlike a Banana
tanoku
96
10k
Large-scale JavaScript Application Architecture
addyosmani
508
110k
Building a Modern Day E-commerce SEO Strategy
aleyda
35
6.8k
Navigating Team Friction
lara
183
13k
The Invisible Customer
myddelton
119
13k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
Done Done
chrislema
180
16k
Web development in the modern age
philhawksworth
204
10k
Become a Pro
speakerdeck
PRO
22
4.8k
The Mythical Team-Month
searls
218
43k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.7k
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