レガシーになりゆくシステムとの向き合い方 / 20221005_inoue

by Rakus_Dev

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#RAKUSMeetup 目次 - 自己紹介 - 楽楽勤怠サービス概要 - レガシーとは - 現在の課題 - 課題に対する施策 - レガシーの進行を止めるために - まとめ

Slide 3

Slide 3 text

#RAKUSMeetup - 井上大輔 / Daisuke Inoue - 経歴 - 2014年 : 銀行案件の孫請SE - 2017年 : 中堅企業で受託開発 - 2017年 : ナビゲーション企業で自社プロダクト開発 - 2021年 : 通信事業会社で自社プロダクト開発 - 2021年 : 株式会社ラクスで楽楽勤怠開発 - 現在 - 楽楽勤怠バックエンド開発に従事 - 勤怠計算チームに所属自己紹介

Slide 4

Slide 4 text

#RAKUSMeetup 楽楽勤怠 - サービス概要 - 2020年10月1日リリース - クラウド上で勤怠管理ができるシステム

Slide 5

Slide 5 text

#RAKUSMeetup 楽楽勤怠システム構成 - フロントエンド - Vue.js, TypeScript - バックエンド - SpringBoot, Java, PostgreSQL

Slide 6

Slide 6 text

#RAKUSMeetup 本日のお題 - レガシーの進行を食い止めたい - リリースから約2年 - まだ食い止められるはず - どう食い止めていくのか？

Slide 7

Slide 7 text

#RAKUSMeetup レガシーとは - レガシーコードとは、単にテストのないコード - テストのないコードは悪いコードである。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているか悪くなっているかが本当にはわからない。

Slide 8

Slide 8 text

#RAKUSMeetup レガシーの何がいけないのか？ - 事業成長のために機能がまだまだ足りない - 必須機能、競合他社機能、差別化機能 - 一定の品質を保ち、速度を下げずに開発しなければならない - テストがないと品質を担保できない - テストがないと仕様が把握できず、開発に時間がかかる

Slide 9

Slide 9 text

#RAKUSMeetup なぜレガシーになりつつあるの？ - 楽楽勤怠では早期PMF実現のために早急な機能開発 - PMF : Product Market Fit - カスタマー（顧客）の課題を満足させる製品を提供し、それが適切な市場に受け入れられている状態 - システム設計者が退職し、システムの複雑化が加速 - プロダクト改善への工数が取れずにいた

Slide 10

Slide 10 text

#RAKUSMeetup - 設計方針とアーキテクチャ - システム設計者曰く実践ドメイン駆動設計を参考に - ドメイン駆動設計 - ヘキサゴナルアーキテクチャ現在の課題の前に

Slide 11

Slide 11 text

#RAKUSMeetup - 複雑なビジネス要件を可能な限りシンプルにモデリングするために使う - ドメインエキスパートと開発者が同じ土俵に上がることで開発者視点だけではなく業務側の視点を踏まえたソフトウェアを作れるように - 対象ソフトウェアを理解している人が一部の人たちだけという状態をなくすドメイン駆動設計

Slide 12

Slide 12 text

#RAKUSMeetup - システムを外部と内部の2つの領域にわける - リクエストはHTTP入力ポートを経て到達しハンドラーがアダプターとして振る舞い処理をアプリケーションサービスに委譲 - クライアントやストレージが確定しないうちからアプリケーション全体とドメインモデルの設計やテストが実施可能ヘキサゴナルアーキテクチャ

Slide 13

Slide 13 text

#RAKUSMeetup - 初めての試み - 書籍を参考に見様見真似で実践 - 緩やかな制約のもとで開発 - 他プロダクトの思想も思想をとりいれつつも

Slide 14

Slide 14 text

#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在

Slide 15

Slide 15 text

#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在

Slide 16

Slide 16 text

#RAKUSMeetup アプリケーション層からのテストのみ - 複雑なビジネス要件を満たすために何百パターンもある秘伝のテストクラス - ドメインモデルに対する単体テストはほぼ存在しない - テストがないのでドメインモデルのアップデートに及び腰になってしまう - ドメイン駆動設計が実践できない

Slide 17

Slide 17 text

#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在

Slide 18

Slide 18 text

#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない - APIインターフェースに顔を出している - アーキテクチャの考え方から外れている依存体質なドメインモデル

Slide 19

Slide 19 text

Slide 20

Slide 20 text

#RAKUSMeetup - Validator、Policyなどにビジネスロジック - Employeeは不完全体で作成できてしまう - 設定される項目の値に対する責務がアプリケーションサービスにビジネスロジックが他のクラスに

Slide 21

Slide 21 text

Slide 22

Slide 22 text

#RAKUSMeetup - どこからでも参照更新が可能 - どこで更新されたのか追えず影響範囲の把握が困難 - アーキテクチャテストでチェックしているが抜け道が存在フィールド変数がpublic

Slide 23

Slide 23 text

Slide 24

Slide 24 text

#RAKUSMeetup - APIのリクエストパラメータにドメインモデルが利用 - アプリケーション層を突き破っており、アーキテクチャから外れている - ドメイン層の実装がコントローラー層に影響 APIインターフェースにも露出

Slide 25

Slide 25 text

#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念

Slide 26

Slide 26 text

#RAKUSMeetup - アプリケーションサービス内でプリミティブ型定義の変数が再代入されていく - 膨大な処理の中で今この変数がどんな状態を表しているのか追えないモデリングされていない概念

Slide 27

Slide 27 text

#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ - DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す課題に対する施策

Slide 28

Slide 28 text

Slide 29

Slide 29 text

#RAKUSMeetup ドメインモデルにビジネスロジック① - 他クラスに委譲していたロジックをそのままドメインモデルに移行 - 移行したロジックに対してテストを書く - 影響範囲が少なくできそう

Slide 30

Slide 30 text

#RAKUSMeetup ドメインモデルにビジネスロジック② - ドメインモデルを生成する際にチェックもしてしまう - 項目に対する責務がアプリケーションサービスからドメインモデルへ - 処理が大きく変わるので書き換え量を鑑みて判断

Slide 31

Slide 31 text

Slide 32

Slide 32 text

#RAKUSMeetup - ORMはDTOを利用するように - DataTransferObject - DBと疎結合 - ORM仕様に依存しない DTOでドメイン層とインフラ層を分離

Slide 33

Slide 33 text

Slide 34

Slide 34 text

#RAKUSMeetup - コントローラー層に新規クラス作成 - 元々利用していたドメインモデルをそのままコピー - 随時不要なロジック削除 - ドメインモデル修正による外部影響がなくなる APIインターフェース用クラス作成

Slide 35

Slide 35 text

Slide 36

Slide 36 text

#RAKUSMeetup モデリングして切り出す - 項目をドメインモデルとして定義 - ビジネスロジックを切り出しドメインモデルに移行 - 特定ドメインに対して見通しが良くなる - 1つずつ処理を追って 1つずつ切り出す

Slide 37

Slide 37 text

#RAKUSMeetup - 湧き上がる気持ちを抑えて冷静に - 全施策実践するぞ - ドメインモデル図全部書くぞ - 全書き換えしてリファクタリング - アーキテクチャ刷新 - ドメインモデルの単体テスト全部書くぞ - 全てやると膨大なタスクで潰れちゃうレガシーの進行を止めるために

Slide 38

Slide 38 text

#RAKUSMeetup - 効果が大きそうなコア機能から - 小さくコツコツ着実に - まずはモデリングして切り出しテスト書く - ドメインを絞ることでドメインの理解が深まる - 既存テストはデグレチェックとして活用 - たとえ小さいドメインだとしてもドメインエキスパートや有識者とすり合わせ - ユースケース図及びドメインモデル図で俯瞰レガシーの進行を止めるために

Slide 39

Slide 39 text

#RAKUSMeetup まとめ - レガシーになりつつあっても事業の歩みは止められない - 湧き上がる気持ちを抑えて冷静に - コア機能から小さくコツコツ着実に