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
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
Search
Rakus_Dev
October 06, 2022
Technology
0
1.6k
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
Rakus_Dev
October 06, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
多様なマネジメント経験から導き出した、事業成長を支えるEMの4つのコンピテンシー / 4 Key EM Competencies for Growth
rakus_dev
1
1k
圧倒的な『顧客志向』の文化の創り方 / Product Engineer Night 20250221
rakus_dev
0
120
読書シェア会 vol.2 / Yumemi.grow 20250225
rakus_dev
0
110
ラクスCTOが語る顧客視点を重視したプロダクト開発 / RAKUSTechCon2024_Kude
rakus_dev
0
2.6k
マルチプロダクトでのプロダクトマネージャーのリアル / RAKUSTechCon2024_Inagaki
rakus_dev
4
4.6k
拡大するマルチプロダクトSaaSの顧客理解にデザイン組織はどう取り組んでいるか / RAKUSTechCon2024_Design
rakus_dev
0
2.4k
急成長する大規模プロダクト開発のマネジメント課題とアプローチ / RAKUSTechCon2024_Seisan
rakus_dev
0
2.4k
パフォーマンス向上とリソース管理のためのアプローチ / RAKUSTechCon2024_RLC
rakus_dev
0
2.2k
急成長するサービスを支えるためのインフラ戦略 / RAKUSTechCon2024_Fujii
rakus_dev
0
2.3k
Other Decks in Technology
See All in Technology
開発者のための FinOps/FinOps for Engineers
oracle4engineer
PRO
2
200
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
150
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
200
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
320
目標と時間軸 〜ベイビーステップでケイパビリティを高めよう〜
kakehashi
PRO
8
840
プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews
nekonenene
1
180
サバイバルモード下でのエンジニアリングマネジメント
konifar
4
810
自分だけの仮想クラスタを高速かつ効率的に作る kubefork
donkomura
0
110
AIエージェント開発のノウハウと課題
pharma_x_tech
8
4.3k
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
9
1.8k
JAWS FESTA 2024「バスロケ」GPS×サーバーレスの開発と運用の舞台裏/jawsfesta2024-bus-gps-serverless
ma2shita
3
280
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
540
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
A designer walks into a library…
pauljervisheath
205
24k
Product Roadmaps are Hard
iamctodd
PRO
51
11k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Building a Scalable Design System with Sketch
lauravandoore
461
33k
RailsConf 2023
tenderlove
29
1k
Practical Orchestrator
shlominoach
186
10k
Music & Morning Musume
bryan
46
6.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Thoughts on Productivity
jonyablonski
69
4.5k
Transcript
#RAKUSMeetup ©2022 RAKUS Co., Ltd. レガシーになりゆく システムとの向き合い方 株式会社ラクス 開発本部 東京開発統括部
楽楽勤怠開発部 楽楽勤怠開発1課 井上 大輔
#RAKUSMeetup 目次 - 自己紹介 - 楽楽勤怠サービス概要 - レガシーとは - 現在の課題
- 課題に対する施策 - レガシーの進行を止めるために - まとめ
#RAKUSMeetup - 井上 大輔 / Daisuke Inoue - 経歴 -
2014年 : 銀行案件の孫請SE - 2017年 : 中堅企業で受託開発 - 2017年 : ナビゲーション企業で自社プロダクト開発 - 2021年 : 通信事業会社で自社プロダクト開発 - 2021年 : 株式会社ラクスで楽楽勤怠開発 - 現在 - 楽楽勤怠バックエンド開発に従事 - 勤怠計算チームに所属 自己紹介
#RAKUSMeetup 楽楽勤怠 - サービス概要 - 2020年10月1日リリース - クラウド上で勤怠管理ができるシステム
#RAKUSMeetup 楽楽勤怠システム構成 - フロントエンド - Vue.js, TypeScript - バックエンド -
SpringBoot, Java, PostgreSQL
#RAKUSMeetup 本日のお題 - レガシーの進行を食い止めたい - リリースから約2年 - まだ食い止められるはず - どう食い止めていくのか?
#RAKUSMeetup レガシーとは - レガシーコードとは、単にテストのないコード - テストのないコードは悪いコードである。テストがあれば、検証し ながらコードの動きを素早く変更することができる。テストがなけ れば、コードが良くなっているか悪くなっているかが本当にはわ からない。
#RAKUSMeetup レガシーの何がいけないのか? - 事業成長のために機能がまだまだ足りない - 必須機能、競合他社機能、差別化機能 - 一定の品質を保ち、速度を下げずに開発しなければならない - テストがないと品質を担保できない
- テストがないと仕様が把握できず、開発に時間がかかる
#RAKUSMeetup なぜレガシーになりつつあるの? - 楽楽勤怠では早期PMF実現のために早急な機能開発 - PMF : Product Market Fit
- カスタマー(顧客)の課題を満足させる製品を提供し、 それが適切な市場に受け入れられている状態 - システム設計者が退職し、システムの複雑化が加速 - プロダクト改善への工数が取れずにいた
#RAKUSMeetup - 設計方針とアーキテクチャ - システム設計者曰く実践ドメイン駆動設計を参考に - ドメイン駆動設計 - ヘキサゴナルアーキテクチャ 現在の課題の前に
#RAKUSMeetup - 複雑なビジネス要件を 可能な限りシンプルにモデリングするために使う - ドメインエキスパートと開発者が同じ土俵に上がることで 開発者視点だけではなく業務側の視点を踏まえた ソフトウェアを作れるように - 対象ソフトウェアを理解している人が
一部の人たちだけという状態をなくす ドメイン駆動設計
#RAKUSMeetup - システムを外部と内部の2つの領域にわける - リクエストはHTTP入力ポートを経て到達し ハンドラーがアダプターとして振る舞い 処理をアプリケーションサービスに委譲 - クライアントやストレージが確定しないうちから アプリケーション全体とドメインモデルの
設計やテストが実施可能 ヘキサゴナルアーキテクチャ
#RAKUSMeetup - 初めての試み - 書籍を参考に見様見真似で実践 - 緩やかな制約のもとで開発 - 他プロダクトの思想も 思想をとりいれつつも
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在
#RAKUSMeetup アプリケーション層からのテストのみ - 複雑なビジネス要件を満たすために 何百パターンもある秘伝のテストクラス - ドメインモデルに対する単体テストはほぼ存在しない - テストがないのでドメインモデルのアップデートに 及び腰になってしまう
- ドメイン駆動設計が実践できない
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - Validator、Policyなどに ビジネスロジック - Employeeは不完全体で 作成できてしまう - 設定される項目の値に対する 責務がアプリケーションサー
ビスに ビジネスロジックが他のクラスに
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - どこからでも参照更新が可能 - どこで更新されたのか追えず 影響範囲の把握が困難 - アーキテクチャテストで チェックしているが 抜け道が存在
フィールド変数がpublic
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - APIのリクエストパラメータに ドメインモデルが利用 - アプリケーション層を突き 破っており、アーキテクチャか ら外れている - ドメイン層の実装が
コントローラー層に影響 APIインターフェースにも露出
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念
#RAKUSMeetup - アプリケーションサービス内で プリミティブ型定義の変数が 再代入されていく - 膨大な処理の中で 今この変数がどんな状態を 表しているのか追えない モデリングされていない概念
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup ドメインモデルにビジネスロジック① - 他クラスに委譲していたロジックを そのままドメインモデルに移行 - 移行したロジックに対してテストを書く - 影響範囲が少なくできそう
#RAKUSMeetup ドメインモデルにビジネスロジック② - ドメインモデルを生成する際に チェックもしてしまう - 項目に対する責務が アプリケーションサービスから ドメインモデルへ -
処理が大きく変わるので 書き換え量を鑑みて判断
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup - ORMはDTOを利用するように - DataTransferObject - DBと疎結合 - ORM仕様に依存しない DTOでドメイン層とインフラ層を分離
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup - コントローラー層に新規クラス作成 - 元々利用していたドメインモデルを そのままコピー - 随時不要なロジック削除 - ドメインモデル修正による
外部影響がなくなる APIインターフェース用クラス作成
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup モデリングして切り出す - 項目をドメインモデルとして定義 - ビジネスロジックを切り出し ドメインモデルに移行 - 特定ドメインに対して 見通しが良くなる
- 1つずつ処理を追って 1つずつ切り出す
#RAKUSMeetup - 湧き上がる気持ちを抑えて冷静に - 全施策実践するぞ - ドメインモデル図全部書くぞ - 全書き換えしてリファクタリング -
アーキテクチャ刷新 - ドメインモデルの単体テスト全部書くぞ - 全てやると膨大なタスクで潰れちゃう レガシーの進行を止めるために
#RAKUSMeetup - 効果が大きそうなコア機能から - 小さくコツコツ着実に - まずはモデリングして切り出しテスト書く - ドメインを絞ることでドメインの理解が深まる -
既存テストはデグレチェックとして活用 - たとえ小さいドメインだとしても ドメインエキスパートや有識者とすり合わせ - ユースケース図及びドメインモデル図で俯瞰 レガシーの進行を止めるために
#RAKUSMeetup まとめ - レガシーになりつつあっても事業の歩みは止められない - 湧き上がる気持ちを抑えて冷静に - コア機能から小さくコツコツ着実に