$30 off During Our Annual Pro Sale. View Details »

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

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

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

Takahashi Ikki

April 04, 2023
Tweet

More Decks by Takahashi Ikki

Other Decks in Programming

Transcript

  1. DBリファクタリングのデータリモデリング勘所
    2023-04-06 突撃!隣のデータ設計・活用勉強会 vol.1
    高橋 一騎 ( @ikkitang )

    View Slide

  2. 本セッションについて
    ● スライドはすでに公開しています。
    ● 質問はslidoやZoomチャットに投稿して貰えれば後で拾えるのでご
    利用ください
    ● このセッションは私の経験を元に「システムリプレイス」に
    おいて、なぜデータリモデリングをするのか、また実際にどのように
    進めていくのか、といった事をご紹介します。
    ● このセッションを通して、システムリプレイスを進めていく時にDBリ
    ファクタリングをどのように進めるかというポイントを
    参考情報として持って帰って頂けるようであれば幸いです。

    View Slide

  3. おしながき
    1. 自己紹介
    2. DBリファクタリングの目的
    3. DBリファクタリングの進め方

    View Slide

  4. 自己紹介
    ● 高橋 一騎 (@ikkitang)
    ● スターフェスティバル株式会社
    TechPdM / Backendエンジニア
    ● 岡山でフルリモート勤務中
    ● 好きなAWS サービス
    ECS Fargate
    Photo by Pixabay

    View Slide

  5. DBリファクタリングの目的
    Photo by Pixabay

    View Slide

  6. ● 技術的負債の解消したい
    ● 新技術を導入する事で素早く価値提供をしたい
    ● 利便性の悪さを一気に解消したい
    上記以外にも色々な理由でシステムリプレースを検討する。
    何のためにシステムリプレースをするのか

    View Slide

  7. 何のためにシステムリプレースをするのか
    ● フレームワークのバージョンをあげよう!!
    ● TypeScript( or Go or Rust) で書いていこう!!
    ● SPA化して React で書くぞ〜!!
    開発のしやすさが上がって、
    より素早く価値提供が出来ていく。
    ただ、これで得られるものは
    「キレイな旧システム」である事が多い。

    View Slide

  8. 何のためにシステムリプレースをするのか
    是非、開発の利便性の向上に加えて
    既存のシステムの機能やそれによって発生している運用を見直してやら
    なくて良い事を見出して機能を見直しする事も
    実践してもらいたい。
    => 利用ユーザーは今のシステムが最善だと思っていない。
    複雑な運用フローが生まれていたり,
    無理矢理な仕様変更によって複雑なコード・運用になってたり。

    View Slide

  9. 要らない物を見直す事を検討すること
    例えばこういう奴 ↓↓↓

    View Slide

  10. 要らない物を見直す事を検討すること
    一見、レイヤーで分割されて綺麗なコー
    ドっぽくなってる。
    でも、実態は
    契約ステータスは廃止されてる
    って事がある。
    これが「キレイな旧システム」の罠

    View Slide

  11. 要らない物を見直す事を検討すること
    注文ステータスが様々な運用ルールで定義されている。
    ● 社内で安全な注文かをチェックする(注文情報精査中)
    ● 安全な注文である事を確認した事をマーク(注文情報精査済)
    ● お客様に発注(発注済み)
    ● 発注後に変更をした(発注済み(変更))
    ● その後にキャンセルした
    (発注後キャンセル(キャンセル率100%))
    綺麗なUIを設計して見易くする事はできるが、そのまま移行すると、認知
    負荷が高い状態は続く。結果運用フローの負担も高いまま

    View Slide

  12. 新しい技術を導入するなどして技術的な負債を解消すると共に、
    現時点での運用フローを見直したり、最新のドメインに追従するなどし
    て、複雑になっているドメインの負債も解消する事を目的に
    システムリプレースを行う。
    => リモデリング(DBリファクタリング)のスキルが必要不可欠。
    (もちろん、アプリケーションのリファクタリングのスキルも必要ですね)
    DBリファクタリングの目的

    View Slide

  13. DBリファクタリングの実践
    Photo by Pixabay

    View Slide

  14. リプレースにおける大事な事はびっくりさせない事だと思います
    既に運用上無くなった物を消す事はそれほどでも無いですが、
    今ある物を新しいものに置き換える時は
    思わぬ所で不安感を与えがちです。
    「私の今のこの仕事はどうなるの?」とか。
    なので、抑える所を抑えながら最速で実践していくような
    仕組み作りが大事だな、と思っています。
    DBリファクタリングの実践

    View Slide

  15. リモデリングを実践する為にやる事は以下です。
    ● 現状を把握して文字起こしする
    ● リプレース後の対比の認識合わせをする
    ● 大枠のリレーション図を書く
    ● ER図を完成させる
    ● ドメインとして使用する単語についてチーム感で意思統一する
    DBリファクタリングの実践

    View Slide

  16. 何はともあれ把握していく事は大事。
    コードから読み取れる部分は読み取りつつ、
    社内管理画面であれば実際に管理画面を使っている方に聞いて
    解像度を上げていく。
    これが終わったら、聞いたことを元に文字起こしの作業をする。
    現状を把握して文字起こしする

    View Slide

  17. 「文字起こし」をする事の目的の一つは
    聞いた人(非エンジニア想定)に「これであってますか?」が
    できる状態を目指したい、って所にある。
    要は形になった物があれば「これはここが違いますね」といった
    フィードバックがもらえる。
    冒頭の「びっくりさせない」為のアウトプットにもなる。
    最終これを改善する事でユースケース駆動開発のように
    進める事も可能だと思ってる。
    現状を把握して文字起こしする

    View Slide

  18. Connpassを例にすると (雑な例ですが)
    ● 管理者はイベント管理画面でイベント情報を入力し登録する
    ● イベントを登録すると未公開状態で保存される
    ○ この間は管理者以外、このイベントを見る事が出来ない
    ○ イベントの管理者として登録された人は、公開前のイベントも見
    る事ができる
    ○ イベントを公開するとイベントページに訪れた人は誰でも見える
    ようになる
    ● イベント参加者がイベントを開いて、予約すると参加者として登録さ
    れる。
    現状を把握して文字起こしする

    View Slide

  19. 文字だけだと目が滑るので
    最近右図のような感じで
    補足ような図を作ったりもす

    フロー図を書いたりとか。
    現状を把握して文字起こしする

    View Slide

  20. 大体、問題なさそうなら モノ(エンティティ)とコト(イベント)に分ける.
    ● 管理者はイベント管理画面でイベント情報を入力し登録する
    ● イベントを登録すると未公開状態のイベントとして保存される
    ○ 未公開状態のイベントは管理者以外見る事が出来ない
    ○ イベントの共同管理者として登録された人は、未公開状態のイベ
    ントも見る事ができる
    ○ イベントを公開するとイベントページに訪れた人は誰でも見える
    ようになる
    ● イベントページに訪れた人がイベントを予約すると
    イベント参加者として登録される。
    現状を把握して文字起こしする

    View Slide

  21. 現状を把握して文字起こしする
    モノ(エンティティ)
    イベント情報
    未公開状態のイベント
    公開状態のイベント
    イベントの共同管理者
    イベントの参加者
    コト(イベント)
    イベントを登録
    イベントを公開
    イベントを予約

    View Slide

  22. モデルに複雑になっている箇所が無いか把握していく。
    例えば....こういうの.
    ● 以前は会場設定が必須だったけど、コロナ対応で
    「空欄にすればオンライン開催として登録できる」とした。
    ● 今、イベントには会場情報は1つしか持てないが、
    住所が必須なオフライン会場 | URLが必須なオンライン会場
    と2つ持てる状態にして、それぞれで正しい状態が担保できる所を目
    指すのはどうか?
    リプレース後の対比を認識合わせする

    View Slide

  23. 自分の図のセンスの無さに驚きますが、
    図解とかして、Before/After の認識合わせしておくと良い
    リプレース後の対比を認識合わせする

    View Slide

  24. ここで示してたのは例でしたが、
    このタイミングが仕様変更による技術的負債を解消するチャンス!!!!
    仕様変更後のシステムを俯瞰的に見て、正しいモデルを
    再考できるのは強くてニューゲームみたいな事だと思います。
    これをちゃんとする事で “悪気無く” 「キレイな旧システム」を
    作ってしまう事が減ってくる。
    リプレース後の対比を認識合わせする

    View Slide

  25. 先程抽出したエンティティとかを
    リレーション図に起こす
    エンティティの関係の表現と
    イベントが〇〇日時と表現が
    されていればOK. ( PKとかも不要 )
    いきなりER図書くと文字起こしの
    内容が漏れるとかあったので
    ER図まで刻む意図でやってる
    大枠のリレーション図を書く

    View Slide

  26. PKを定義したりテーブルを
    分割したりしてER図を完成させる
    イミュータブルデータモデリング
    ってのをやっていて
    一個のテーブルで一個のイベントが
    対応するように設計する
    ER図を完成させる

    View Slide

  27. イベント情報を
    更新する
    イベント共通
    管理者を登録す

    ER図を完成させる
    イベント情報を
    入力して登録する
    イベントを
    公開する
    イベントを
    予約する

    View Slide

  28. 大体、1テーブル1イベントとかを
    ふまえて作っておくと
    そんなに失敗しないはず。
    集約の単位も小さくなるので
    アプリケーションも
    そこまで困らないはず。
    ER図を完成させる

    View Slide

  29. ER図が完成したら
    それぞれをどのような”英語”で
    表現すると認識がズレにくいかをチーム
    で議論します。
    ● イベント内容
    ○ event_content
    ○ event_information
    ○ event_detail
    ドメインとして使用する単語を統一する

    View Slide

  30. 後は新しいDBに沿って書いていくだけ!!
    Photo by Pixabay

    View Slide

  31. ● こういうのとか →
    ○ https://speakerdeck.com/takahashi
    ikki/postgresqljapan2018
    ● Debezium を使った移行
    とかも出来そうですね!
    ○ https://github.com/TakahashiIkki/d
    ms-local-develop
    多少の知見があります!
    既存システムとの並行稼働の壁

    View Slide

  32. まとめ
    Photo by Pixabay

    View Slide

  33. ● システムリプレースはリファクタリングでは無いので
    同じ挙動にしない事に臆せず挑戦していきましょう
    ● そのためには現在の課題を把握する事は重要なので
    ヒアリングや調査をして現在の課題を把握する事が大切
    ● モデリングはチームで進めていくので
    運用のBefore/After
    ドメインモデルのBefore/After
    これらをそれぞれ認識しながら進めていきましょう
    ● Go All Out でやっていきましょう
    ○ ( スタフェスのバリュー . 困難な課題を解決する為にチームが一丸となってあらゆる課題に
    常にチャレンジしてやり遂げていく )
    まとめ

    View Slide

  34. ありがとうございました
    Photo by Pixabay

    View Slide