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.7k
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
Rakus_Dev
October 06, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
AIは精算業務をどう変える? 自律型エージェントが実現する未来のワークフロー / RAKUS AI Meetup-1
rakus_dev
0
9
メールディーラーにおけるAI活用事例 ~クレーム検知機能リリースの舞台裏~ / RAKUS AI Meetup-2
rakus_dev
0
7
ラクス開発本部のAI駆動開発推進事例 / RAKUS AI Meetup-3
rakus_dev
0
20
読書シェア会 vol.5 / Yumemi.grow 20250526
rakus_dev
0
1.6k
PdM採用とAIの製品活用を同時に頑張ってみた話 / EM oasis 20250418
rakus_dev
0
180
多様なマネジメント経験から導き出した、事業成長を支えるEMの4つのコンピテンシー / 4 Key EM Competencies for Growth
rakus_dev
2
2.2k
圧倒的な『顧客志向』の文化の創り方 / Product Engineer Night 20250221
rakus_dev
0
330
読書シェア会 vol.2 / Yumemi.grow 20250225
rakus_dev
0
160
ラクスCTOが語る顧客視点を重視したプロダクト開発 / RAKUSTechCon2024_Kude
rakus_dev
0
3.1k
Other Decks in Technology
See All in Technology
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
470
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
210
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
6.9k
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
120
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
2.4k
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.2k
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
130
いつの間にか入れ替わってる!?新しいAWS Security Hubとは?
cmusudakeisuke
0
120
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
380
american airlines®️ USA Contact Numbers: Complete 2025 Support Guide
supportflight
1
110
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
7.5k
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
510
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
It's Worth the Effort
3n
185
28k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Embracing the Ebb and Flow
colly
86
4.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
820
Building Applications with DynamoDB
mza
95
6.5k
How GitHub (no longer) Works
holman
314
140k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
What's in a price? How to price your products and services
michaelherold
246
12k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.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 まとめ - レガシーになりつつあっても事業の歩みは止められない - 湧き上がる気持ちを抑えて冷静に - コア機能から小さくコツコツ着実に