Slide 1
Slide 1 text
DBリファクタリングのデータリモデリング勘所
2023-04-06 突撃！隣のデータ設計・活用勉強会 vol.1
高橋 一騎 ( @ikkitang )
Slide 2
Slide 2 text
本セッションについて
● スライドはすでに公開しています。
● 質問はslidoやZoomチャットに投稿して貰えれば後で拾えるのでご
利用ください
● このセッションは私の経験を元に「システムリプレイス」に
おいて、なぜデータリモデリングをするのか、また実際にどのように
進めていくのか、といった事をご紹介します。
● このセッションを通して、システムリプレイスを進めていく時にDBリ
ファクタリングをどのように進めるかというポイントを
参考情報として持って帰って頂けるようであれば幸いです。
Slide 3
Slide 3 text
おしながき
1. 自己紹介
2. DBリファクタリングの目的
3. DBリファクタリングの進め方
Slide 4
Slide 4 text
自己紹介
● 高橋 一騎 (@ikkitang)
● スターフェスティバル株式会社
TechPdM / Backendエンジニア
● 岡山でフルリモート勤務中
● 好きなAWS サービス
ECS Fargate
Photo by Pixabay
Slide 5
Slide 5 text
DBリファクタリングの目的
Photo by Pixabay
Slide 6
Slide 6 text
● 技術的負債の解消したい
● 新技術を導入する事で素早く価値提供をしたい
● 利便性の悪さを一気に解消したい
上記以外にも色々な理由でシステムリプレースを検討する。
何のためにシステムリプレースをするのか
Slide 7
Slide 7 text
何のためにシステムリプレースをするのか
● フレームワークのバージョンをあげよう！！
● TypeScript( or Go or Rust) で書いていこう！！
● SPA化して React で書くぞ〜！！
開発のしやすさが上がって、
より素早く価値提供が出来ていく。
ただ、これで得られるものは
「キレイな旧システム」である事が多い。
Slide 8
Slide 8 text
何のためにシステムリプレースをするのか
是非、開発の利便性の向上に加えて
既存のシステムの機能やそれによって発生している運用を見直してやら
なくて良い事を見出して機能を見直しする事も
実践してもらいたい。
=> 利用ユーザーは今のシステムが最善だと思っていない。
複雑な運用フローが生まれていたり,
無理矢理な仕様変更によって複雑なコード・運用になってたり。
Slide 9
Slide 9 text
要らない物を見直す事を検討すること
例えばこういう奴 ↓↓↓
Slide 10
Slide 10 text
要らない物を見直す事を検討すること
一見、レイヤーで分割されて綺麗なコー
ドっぽくなってる。
でも、実態は
契約ステータスは廃止されてる
って事がある。
これが「キレイな旧システム」の罠
Slide 11
Slide 11 text
要らない物を見直す事を検討すること
注文ステータスが様々な運用ルールで定義されている。
● 社内で安全な注文かをチェックする（注文情報精査中）
● 安全な注文である事を確認した事をマーク（注文情報精査済）
● お客様に発注（発注済み）
● 発注後に変更をした（発注済み（変更））
● その後にキャンセルした
（発注後キャンセル（キャンセル率100%））
綺麗なUIを設計して見易くする事はできるが、そのまま移行すると、認知
負荷が高い状態は続く。結果運用フローの負担も高いまま
Slide 12
Slide 12 text
新しい技術を導入するなどして技術的な負債を解消すると共に、
現時点での運用フローを見直したり、最新のドメインに追従するなどし
て、複雑になっているドメインの負債も解消する事を目的に
システムリプレースを行う。
=> リモデリング（DBリファクタリング）のスキルが必要不可欠。
（もちろん、アプリケーションのリファクタリングのスキルも必要ですね）
DBリファクタリングの目的
Slide 13
Slide 13 text
DBリファクタリングの実践
Photo by Pixabay
Slide 14
Slide 14 text
リプレースにおける大事な事はびっくりさせない事だと思います
既に運用上無くなった物を消す事はそれほどでも無いですが、
今ある物を新しいものに置き換える時は
思わぬ所で不安感を与えがちです。
「私の今のこの仕事はどうなるの？」とか。
なので、抑える所を抑えながら最速で実践していくような
仕組み作りが大事だな、と思っています。
DBリファクタリングの実践
Slide 15
Slide 15 text
リモデリングを実践する為にやる事は以下です。
● 現状を把握して文字起こしする
● リプレース後の対比の認識合わせをする
● 大枠のリレーション図を書く
● ER図を完成させる
● ドメインとして使用する単語についてチーム感で意思統一する
DBリファクタリングの実践
Slide 16
Slide 16 text
何はともあれ把握していく事は大事。
コードから読み取れる部分は読み取りつつ、
社内管理画面であれば実際に管理画面を使っている方に聞いて
解像度を上げていく。
これが終わったら、聞いたことを元に文字起こしの作業をする。
現状を把握して文字起こしする
Slide 17
Slide 17 text
「文字起こし」をする事の目的の一つは
聞いた人（非エンジニア想定）に「これであってますか？」が
できる状態を目指したい、って所にある。
要は形になった物があれば「これはここが違いますね」といった
フィードバックがもらえる。
冒頭の「びっくりさせない」為のアウトプットにもなる。
最終これを改善する事でユースケース駆動開発のように
進める事も可能だと思ってる。
現状を把握して文字起こしする
Slide 18
Slide 18 text
Connpassを例にすると (雑な例ですが)
● 管理者はイベント管理画面でイベント情報を入力し登録する
● イベントを登録すると未公開状態で保存される
○ この間は管理者以外、このイベントを見る事が出来ない
○ イベントの管理者として登録された人は、公開前のイベントも見
る事ができる
○ イベントを公開するとイベントページに訪れた人は誰でも見える
ようになる
● イベント参加者がイベントを開いて、予約すると参加者として登録さ
れる。
現状を把握して文字起こしする
Slide 19
Slide 19 text
文字だけだと目が滑るので
最近右図のような感じで
補足ような図を作ったりもす
る
フロー図を書いたりとか。
現状を把握して文字起こしする
秘
Slide 20
Slide 20 text
大体、問題なさそうなら モノ（エンティティ）とコト（イベント）に分ける.
● 管理者はイベント管理画面でイベント情報を入力し登録する
● イベントを登録すると未公開状態のイベントとして保存される
○ 未公開状態のイベントは管理者以外見る事が出来ない
○ イベントの共同管理者として登録された人は、未公開状態のイベ
ントも見る事ができる
○ イベントを公開するとイベントページに訪れた人は誰でも見える
ようになる
● イベントページに訪れた人がイベントを予約すると
イベント参加者として登録される。
現状を把握して文字起こしする
Slide 21
Slide 21 text
現状を把握して文字起こしする
モノ（エンティティ）
イベント情報
未公開状態のイベント
公開状態のイベント
イベントの共同管理者
イベントの参加者
コト（イベント）
イベントを登録
イベントを公開
イベントを予約
Slide 22
Slide 22 text
モデルに複雑になっている箇所が無いか把握していく。
例えば....こういうの.
● 以前は会場設定が必須だったけど、コロナ対応で
「空欄にすればオンライン開催として登録できる」とした。
● 今、イベントには会場情報は1つしか持てないが、
住所が必須なオフライン会場 | URLが必須なオンライン会場
と2つ持てる状態にして、それぞれで正しい状態が担保できる所を目
指すのはどうか？
リプレース後の対比を認識合わせする
Slide 23
Slide 23 text
自分の図のセンスの無さに驚きますが、
図解とかして、Before/After の認識合わせしておくと良い
リプレース後の対比を認識合わせする
Slide 24
Slide 24 text
ここで示してたのは例でしたが、
このタイミングが仕様変更による技術的負債を解消するチャンス!!!!
仕様変更後のシステムを俯瞰的に見て、正しいモデルを
再考できるのは強くてニューゲームみたいな事だと思います。
これをちゃんとする事で “悪気無く” 「キレイな旧システム」を
作ってしまう事が減ってくる。
リプレース後の対比を認識合わせする
Slide 25
Slide 25 text
先程抽出したエンティティとかを
リレーション図に起こす
エンティティの関係の表現と
イベントが〇〇日時と表現が
されていればOK. ( PKとかも不要 )
いきなりER図書くと文字起こしの
内容が漏れるとかあったので
ER図まで刻む意図でやってる
大枠のリレーション図を書く
Slide 26
Slide 26 text
PKを定義したりテーブルを
分割したりしてER図を完成させる
イミュータブルデータモデリング
ってのをやっていて
一個のテーブルで一個のイベントが
対応するように設計する
ER図を完成させる
Slide 27
Slide 27 text
イベント情報を
更新する
イベント共通
管理者を登録す
る
ER図を完成させる
イベント情報を
入力して登録する
イベントを
公開する
イベントを
予約する
Slide 28
Slide 28 text
大体、1テーブル1イベントとかを
ふまえて作っておくと
そんなに失敗しないはず。
集約の単位も小さくなるので
アプリケーションも
そこまで困らないはず。
ER図を完成させる
Slide 29
Slide 29 text
ER図が完成したら
それぞれをどのような”英語”で
表現すると認識がズレにくいかをチーム
で議論します。
● イベント内容
○ event_content
○ event_information
○ event_detail
ドメインとして使用する単語を統一する
Slide 30
Slide 30 text
後は新しいDBに沿って書いていくだけ!!
Photo by Pixabay
Slide 31
Slide 31 text
● こういうのとか →
○ https://speakerdeck.com/takahashi
ikki/postgresqljapan2018
● Debezium を使った移行
とかも出来そうですね！
○ https://github.com/TakahashiIkki/d
ms-local-develop
多少の知見があります!
既存システムとの並行稼働の壁
Slide 32
Slide 32 text
まとめ
Photo by Pixabay
Slide 33
Slide 33 text
● システムリプレースはリファクタリングでは無いので
同じ挙動にしない事に臆せず挑戦していきましょう
● そのためには現在の課題を把握する事は重要なので
ヒアリングや調査をして現在の課題を把握する事が大切
● モデリングはチームで進めていくので
運用のBefore/After
ドメインモデルのBefore/After
これらをそれぞれ認識しながら進めていきましょう
● Go All Out でやっていきましょう
○ ( スタフェスのバリュー . 困難な課題を解決する為にチームが一丸となってあらゆる課題に
常にチャレンジしてやり遂げていく )
まとめ
Slide 34
Slide 34 text
ありがとうございました
Photo by Pixabay