DBリファクタリングのデータリモデリング勘所/stafesstudy-db-modling

このセッションは私の経験を元に「システムリプレイス」に
おいて、なぜデータリモデリングをするのか、また実際にどのように進めていくのか、といった事をご紹介します。
このセッションを通して、システムリプレイスを進めていく時にDBリファクタリングをどのように進めるかというポイントを
参考情報として持って帰って頂けるようであれば幸いです。

Transcript

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