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.4k
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
Rakus_Dev
October 06, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
ARR100億超SaaSをさらに成長させるPdM組織の立ち上げと今後について
rakus_dev
0
450
B2B SaaSでSpringSecurityによる Roleを用いたユーザー権限設定の 実装について
rakus_dev
1
320
22歳になる長寿サービスのUI刷新 ~密結合システムからViewを分離した苦労話
rakus_dev
1
3.3k
【ラクステックカンファレンス2023】オープニングセッション/20230208_kude
rakus_dev
1
800
短納期でも進化をあきらめなかった新規プロダクト開発/20230208_matsuura_kawakami
rakus_dev
0
780
フロントエンド横断組織のチームトポロジー/20230208_kunieda
rakus_dev
0
980
ベテラン社員が抜けても若手が成長できるエンジニア組織づくり/20230208_otsuka_aramaki_kuyama
rakus_dev
0
800
デザイン組織が社内下請けから脱却するためにやったこと/20230208_kobayashi
rakus_dev
1
840
ゼロから始めるクラウドネイティブ/20230208_mikata_matsumoto
rakus_dev
0
740
Other Decks in Technology
See All in Technology
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
12
7.8k
PhpStorm超絶技巧40分集中講義 #phpconkagawa
yusuke
2
510
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
210
パフォーマンス最適化のベストプラクティス
databricksjapan
0
130
TiDBにおけるテーブル設計と最適化の事例
cygames
0
660
自らを知り外と繋がる、日経のエンジニア採用とDevRel活動/devreljp92
nishiuma
2
210
Max out Local LLM in Challenging Environments
sashimimochi
2
230
RailsConf 2024 Keynote "Startups on Rails in 2024"
irinanazarova
0
170
M&A戦略を支えるデータマネジメント (MIDAS Tech Study #16 GENDA Komiyama)
kommy339
1
170
推し活の1つとしての株購入~みんなでソラコムの株主になろう~
kenichirokimura
0
100
NewSQL Landscape
oracle4engineer
PRO
5
3k
高専で制御を、大学でセンシングを学び、次は脳みそ
satoshirobatofujimoto
0
120
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
32
47k
Statistics for Hackers
jakevdp
790
220k
Designing the Hi-DPI Web
ddemaree
276
33k
Code Reviewing Like a Champion
maltzj
515
39k
Documentation Writing (for coders)
carmenintech
60
4k
Fireside Chat
paigeccino
22
2.6k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
No one is an island. Learnings from fostering a developers community.
thoeni
16
2.1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
66
14k
The Language of Interfaces
destraynor
151
23k
How STYLIGHT went responsive
nonsquared
92
4.8k
For a Future-Friendly Web
brad_frost
172
9k
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 まとめ - レガシーになりつつあっても事業の歩みは止められない - 湧き上がる気持ちを抑えて冷静に - コア機能から小さくコツコツ着実に