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
ラクスCTOが語る顧客視点を重視したプロダクト開発 / RAKUSTechCon2024_Kude
rakus_dev
0
2.5k
マルチプロダクトでのプロダクトマネージャーのリアル / RAKUSTechCon2024_Inagaki
rakus_dev
4
4.4k
拡大するマルチプロダクトSaaSの顧客理解にデザイン組織はどう取り組んでいるか / RAKUSTechCon2024_Design
rakus_dev
0
2.3k
急成長する大規模プロダクト開発のマネジメント課題とアプローチ / RAKUSTechCon2024_Seisan
rakus_dev
0
2.3k
パフォーマンス向上とリソース管理のためのアプローチ / RAKUSTechCon2024_RLC
rakus_dev
0
2.2k
急成長するサービスを支えるためのインフラ戦略 / RAKUSTechCon2024_Fujii
rakus_dev
0
2.2k
楽楽精算のQA改革 / RAKUSTechCon2024_Kaneko
rakus_dev
1
2.2k
新たな顧客課題に挑む17年目の進化とモダナイゼーション / RAKUSTechCon2024_Haihaimail
rakus_dev
1
2.2k
クロージングトーク / RAKUSTechCon2024_Closingtalk
rakus_dev
0
2.1k
Other Decks in Technology
See All in Technology
Active Directory の保護
eurekaberry
6
3.4k
Creative Pair
kawaguti
PRO
1
150
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移
mtpooh
1
370
日経電子版 x AIエージェントの可能性とAgentic RAGによって提案書生成を行う技術
masahiro_nishimi
1
180
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
120k
20250208_OpenAIDeepResearchがやばいという話
doradora09
PRO
0
130
“自分”を大切に、フラットに。キャリアチェンジしてからの一年 三ヶ月で見えたもの。
maimyyym
0
310
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
snoozer05
PRO
20
4.3k
日本語プログラミングとSpring Bootアプリケーション開発 #kanjava
yusuke
2
370
Grid表示のレイアウトで Flow layoutsを使う
cffyoha
1
160
パフォーマンスとコスト改善のために法人データ分析基盤をBigQueryに移行した話
seiya303
1
110
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
335
57k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Bash Introduction
62gerente
610
210k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Agile that works and the tools we love
rasmusluckow
328
21k
Building Your Own Lightsaber
phodgson
104
6.2k
Statistics for Hackers
jakevdp
797
220k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
39
1.9k
The Invisible Side of Design
smashingmag
299
50k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
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 まとめ - レガシーになりつつあっても事業の歩みは止められない - 湧き上がる気持ちを抑えて冷静に - コア機能から小さくコツコツ着実に