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