DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD

DDDでレガシーコードに立ち向かうリアル〜躓きと学び〜 2024年3月24日 Object-Oriented Conference 2024 株式会社コドモン中田義人

2 経歴プロダクト開発チームにて請求・決済関連機能のアプリケーション開発に携わる。整理整頓が好き。最近の趣味はガンプラ。自己紹介中田義人なかたよしと 2009.04
前職のSIerに新卒入社 2022.11 コドモンに開発エンジニアとして入社

3 Mission

4 すべての先生に子どもと向き合う時間と心のゆとりをこんなプロダクトを開発していますメインプロダクトは、保育・教育施設向けWebアプリケーション。保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版アプリケーション、外部サービスと連携するAPIなども開発しています。

5 はじめに

6 レガシーコードにDDDの考え方を取り入れたいけどどこからどう手をつけたらよいかわからない

7 DDDを取り入れてはみたがいろいろな概念や設計パターンをちゃんと理解して、上手く使えているか、自信がない

8 そんなあなたの背中を押したい！

9 コドモンではどんな感じなのか赤裸々にお伝えします

10 今日話すことコドモンのレガシーコードの現状 DDDの実践と躓き得られた学びとこれから 1 2 3

11 • DDDを組織にどのように導入したか • DDDの概念や設計パターンの詳細説明今日話さないこと

12 今日話すことコドモンのレガシーコードの現状 DDDの実践と躓き得た学びとこれから 1 2 3

13 CONFIDENTIAL - © 2022 CoDMON Inc. 13 1. コドモンのレガシーコードの現状
プロダクトと開発組織の急速な成長エンジニア数 65人 2024年3月現在業務委託含む

保守性の重要度があがってきた

15 CONFIDENTIAL - © 2022 CoDMON Inc. 15 Domain Usecase
Presentation Infrastructure Tests E2E/IT 1. コドモンのレガシーコードの現状 File File File File Class Class Class Class Class Class Class API API API API API API API API • API Endpointごとに 1ファイルにほぼ全処理が書かれている • 手動テスト（E2Eのみ） gauge gauge gauge gauge ほぼ手動モノリス（バックエンド）はモジュラーモノリスを目指す • コンテキスト × レイヤーでモジュールを分割 • 自動テスト（E2E/IT/UT） gauge gauge Class Bounded Context A Bounded Context B リファクタ前の領域リファクタ後の領域

16 CONFIDENTIAL - © 2022 CoDMON Inc. 16 Domain Usecase
Presentation Infrastructure Tests E2E/IT 1. コドモンのレガシーコードの現状 File File File File Class Class Class Class Class Class Class API API API API API API API API • API Endpointごとに 1ファイルにほぼ全処理が書かれている • 手動テスト（E2Eのみ） gauge gauge gauge gauge ほぼ手動モノリス（バックエンド）はモジュラーモノリスを目指す • コンテキスト × レイヤーでモジュールを分割 • 自動テスト（E2E/IT/UT） gauge gauge Class Bounded Context A Bounded Context B リファクタ前の領域リファクタ後の領域改修する部分から順次リファクタして移す

リファクタリングの優先度基本的には、改修が必要な部分からやる（ボーイスカウト・ルール）いま改修が必要な部分　≒　近々、追加改修が必要になる可能性も高い部分ただし、リファクタリングを集中的にやる場合もある。 OOC2024ガイドブック記事

20 CONFIDENTIAL - © 2022 CoDMON Inc. 20 2. DDDの実践と躓き
ご紹介する事例コドモンにおいて、DDDの設計パターンを取り入れてレガシーコードのリファクタリングを行った開発事例として、 2023年度に行ったインボイス制度対応での出来事をご紹介します。

インボイス制度とは • 2023年10月1日から施行された、新しい仕入税額控除の制度 • 適格請求書は正確な適用税率や消費税額等を伝える必要がある国税庁サイトより

コドモンにおけるインボイス制度対応消費税計算ロジックの変更が必要改修するうえで厄介だったこと • 複数の画面・APIで消費税計算が実装されている • 修正が必要なAPIの多くがレガシーコード（先述のリファクタ前の領域） • 制度の施行開始までに開発を間に合わせる必要がある

コドモンにおけるインボイス制度対応どうする？ • 今後の保守性向上のため、ロジックが散らばった状態は是正したい • 改修対象が多いので、本開発のテスト・実装の効率観点でも、ドメインロジックの共通化が必要 ↓ ロジック変更と合わせてリファクタリングも行う

リファクタリングの進め方開発担当チームではリファクタガイドラインを用意していたレガシーコードをリファクタ後の領域に移す手順

リファクタガイドラインの概要既存APIのコード（リファクタ前） Test 自動テスト作成 Step 1 Step 2 Step 3 Step 4 Step 5

リファクタガイドラインの概要既存APIのコード（リファクタ前） Controller Test Test UseCase そのまま移す APIパスだけ変更 Step 1 Step 2 Step 3 Step 4 Step 5

リファクタガイドラインの概要既存APIのコード（リファクタ前） Controller Test Test UseCase Controller UseCase Repositories Models DBアクセスを切り出し Step 1 Step 2 Step 3 Step 4 Step 5

リファクタガイドラインの概要既存APIのコード（リファクタ前） Controller Test Test UseCase Controller UseCase Repositories Models Controller UseCase Repositories Models ドメインロジックを移す Step 1 Step 2 Step 3 Step 4 Step 5

リファクタガイドラインの概要既存APIのコード（リファクタ前） Controller Test Test UseCase Controller UseCase Repositories Models Controller UseCase Repositories Models Controller UseCase Repositories Models req/res検証・変換や認証を移す Step 1 Step 2 Step 3 Step 4 Step 5

リファクタガイドラインの概要既存APIのコード（リファクタ前） Controller Test Test UseCase Controller UseCase Repositories Models Controller UseCase Repositories Models Controller UseCase Repositories Models Step 1 Step 2 Step 3 Step 4 Step 5 繰り返し拡充

リファクタガイドラインの概要既存APIのコード（リファクタ前） Controller Test Test UseCase Controller UseCase Repositories Models Controller UseCase Repositories Models Controller UseCase Repositories Models Step 1 Step 2 Step 3 Step 4 Step 5 どのステップまでやるか、どの部分を切り出すか見積の際にチームで認識を合わせる

32 CONFIDENTIAL - © 2022 CoDMON Inc. 32 ドメインの概要 2.
DDDの実践と躓き

33 CONFIDENTIAL - © 2022 CoDMON Inc. 33 インボイス対応で扱ったドメインモデルの概要 2.
DDDの実践と躓き

34 CONFIDENTIAL - © 2022 CoDMON Inc. 34 インボイス対応で扱ったドメインモデルの概要 2.
DDDの実践と躓き 2024年3月の山田太郎（園児）さん分の請求園児ごと月単位の「請求情報」項目名単価数量価格税種別税率月極保育料 15,000 1 15,000 非課税延長保育料 2,000 1 2,000 非課税教材費 500 1 500 税抜 10% バス送迎 1,000 1 1,000 税抜 10% 「請求情報」は「請求明細」を複数もつ請求額(消費税)の計算単位

項目名税抜金額消費税額税率月極保育料 40,000 - 非課税延長保育料 10,000 - 非課税バス送迎 3,105 311 10% 教材費 645 65 10% 非課税計 50,000 - 10%対象計 3,750 376 項目名税抜金額消費税額税率月極保育料 40,000 - 非課税延長保育料 10,000 - 非課税バス送迎 3,105 - 10% 教材費 645 - 10% 非課税計 50,000 - 10%対象計 3,750 375 ×0.1 ×0.1 合算合算 ×0.1 請求額請求額 ¥54,126 ¥54,125 認められない計算例（変更前）認められる計算例（変更後） ※上記は計算例を示したものです。適格請求書の要件は他にもあります。 1 2 1 2 消費税計算ロジックの変更点

36 CONFIDENTIAL - © 2022 CoDMON Inc. 36 ドメインロジックも大して複雑じゃないし共通化できてしまえば差し替えは簡単でしょ🙂
2. DDDの実践と躓き ↓ 思ったほど上手くいかなかった🫠

37 CONFIDENTIAL - © 2022 CoDMON Inc. 37 参照・更新の単位がまちまち１つのAPIの責務が大きい
思った以上に重複が多い 1 2 3 躓いてわかったコドモンのレガシーコードの課題 2. DDDの実践と躓き

39 CONFIDENTIAL - © 2022 CoDMON Inc. 39 参照・更新の単位がまちまち躓いたAPI　その１
園児の絞り込みテスト用データですこども施設に所属する複数園児の請求額の合計の情報を取得するAPI

40 CONFIDENTIAL - © 2022 CoDMON Inc. 40 既存コードがやっていたこと園児
テーブルクラステーブル請求情報テーブル・・・ JOIN 対象園児の絞り込み入園前・卒園後所属クラス当月の請求状態 etc 請求額（消費税）の計算いろんなテーブルを一度にJOINして取得してから、いろいろ処理している参照・更新の単位がまちまち

41 CONFIDENTIAL - © 2022 CoDMON Inc. 41 既存コードがやっていたこと園児
テーブルクラステーブル請求情報テーブル・・・ JOIN 対象園児の絞り込み入園前・卒園後所属クラス当月の請求状態 etc 請求額（消費税）の計算いろんなテーブルを一度にJOINして取得してから、いろいろ処理しているリポジトリ経由に変えたいところドメインモデルに変えたいところ参照・更新の単位がまちまち

42 CONFIDENTIAL - © 2022 CoDMON Inc. 42 困ったこと園児絞り込み条件と請求額計算の実装が絡み合っている
↓ 請求情報の取得のみをリポジトリに差し替えるのが難しいただし、園児の絞り込みに関わるデータ取得やロジックの全体をリファクタリングしている時間的余裕はない... 参照・更新の単位がまちまち

43 CONFIDENTIAL - © 2022 CoDMON Inc. 43 どうしたか園児
テーブルクラステーブル請求情報テーブル・・・ JOIN 対象園児の絞り込み請求額（消費税）の計算既存のテーブル取得処理は残しつつ、別途リポジトリからモデルを取得するリポジトリ経由で取得園児IDリストを引数として渡す請求額（消費税）の計算テーブルアクセスが冗長だが高負荷処理ではないので妥協参照・更新の単位がまちまち

44 CONFIDENTIAL - © 2022 CoDMON Inc. 44 id child_id
target_date confirm_flag price tax_percentage item_name … 11111113 2000 2023-12-01 0 500 8 おやつ 11111112 2000 2023-12-01 0 3000 10 送迎バス 11111111 2000 2023-11-01 1 2000 0 一時保育 11111110 3000 2023-11-01 1 1000 0 延長保育料請求情報請求情報テーブルを確認したらレコードの単位は「請求明細」（正規化されていない）明細明細既存コードは「請求明細」単位で取得・更新している😕 参照・更新の単位がまちまち

45 CONFIDENTIAL - © 2022 CoDMON Inc. 45 請求情報の更新はどうする？「請求情報」の整合性は更新時にどうチェックしてる？🤔
参照・更新の単位がまちまち

46 CONFIDENTIAL - © 2022 CoDMON Inc. 46 請求情報の更新はどうする？参照・更新の単位がまちまち
請求情報テーブル更新APIのコードを見ると更新API a 更新API b 受け取った請求明細のみチェック請求明細 1 請求明細 2 更新API c 請求明細 1 請求明細 2 請求明細 3 請求明細 3 請求情報のまとまりを意識していないAPIもある

47 CONFIDENTIAL - © 2022 CoDMON Inc. 47 請求情報の更新はどうする？参照・更新の単位がまちまち
請求情報テーブルフロントエンドのコードまで見ると更新API 全ての請求明細を取得請求情報のまとまり請求明細 1 請求明細 2 請求明細 3 参照API フロントエンド全ての請求明細を送信請求情報単位でチェック・処理請求情報のまとまり請求明細 1 請求明細 2 請求明細 3 受け取った請求明細のみチェック

48 CONFIDENTIAL - © 2022 CoDMON Inc. 48 請求情報の更新はどうする？「請求情報」の整合性は更新時にどうチェックしてる？🤔
↓ 複数APIが各々でチェック＋ Frontendで全体チェックただし、複数APIやFrontendに散らばっているチェック仕様をかき集めて、ドメインモデルに確実に移している時間的余裕はない参照・更新の単位がまちまち

49 CONFIDENTIAL - © 2022 CoDMON Inc. 49 どうしたか今回は参照処理のみをDDDでリファクタリングすることにした
• リポジトリは、ﬁndメソッドのみ • ドメインモデルは、参照系メソッド（消費税の計算を含む）のみ今後、更新処理も改修する機会があればリファクタリングしたい... 参照・更新の単位がまちまち

50 なぜこうなった？どうすればよい？

51 CONFIDENTIAL - © 2022 CoDMON Inc. 51 「集約」とは DDDの「集約」の考え方を取り入れてみる
参照・更新の単位がまちまちエンティティと値オブジェクトを集約の中にまとめ、各集約の周囲に境界を定義すること。〜〜〜〜〜〜〜〜〜どんな状態変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて強制する〜〜〜「エリック・エヴァンスのドメイン駆動設計」より抜粋

52 CONFIDENTIAL - © 2022 CoDMON Inc. 52 集約の観点で見ると参照・更新の単位がまちまち
請求明細は集約ルートでもエンティティでもない集約の境界集約ルート

53 CONFIDENTIAL - © 2022 CoDMON Inc. 53 うまくいかなかった要因いろんなテーブルをJOINして
まとめて取得している ↓ 集約より広い範囲をまとめて操作している ↓ 責務が混ざって複雑になる「請求明細」のレコード単位で取得・更新している ↓ 集約の一部だけを個別に操作している ↓ 不変条件を制御しづらい参照・更新の単位がまちまち

54 CONFIDENTIAL - © 2022 CoDMON Inc. 54 参照・更新の単位がまちまち ↓
集約単位で参照・更新する学び参照・更新の単位がまちまち

57 CONFIDENTIAL - © 2022 CoDMON Inc. 57 １つのAPIの責務が大きい躓いたAPI　その２
請求情報を確定して請求額（消費税を含む）を決定するAPI テスト用データです

58 CONFIDENTIAL - © 2022 CoDMON Inc. 58 １つのAPIの責務が大きい請求情報を変更・確定
確定した請求情報を保存保存した請求情報を再取得請求情報を受信請求額（消費税）を計算請求額を入金管理に登録処理の流れ billsテーブルのrecordデータ作成 UPDATE bills SELECT FROM bills APIリクエストbody $bill->price * $bill->tax_percentage INSERT INTO payments 既存コード

確定した請求情報を保存保存した請求情報を再取得請求情報を受信請求額（消費税）を計算請求額を入金管理に登録処理の流れ billsテーブルのrecordデータ作成 UPDATE bills SELECT FROM bills APIリクエストbody $bill->price * $bill->tax_percentage INSERT INTO payments 既存コード修正イメージ $bills = BillRepository->findByChildIds() $bill->priceTotal() リポジトリ取得にするモデルに計算させる

60 CONFIDENTIAL - © 2022 CoDMON Inc. 60 １つのAPIの責務が大きい修正はあっさり完了、しかし
E2Eテストがローカル環境（docker）だと通るのに検証環境（AWS）だと通らない

確定した請求情報を保存保存した請求情報を再取得請求情報を受信請求額（消費税）を計算請求額を入金管理に登録テストが、ローカル環境だと通るのに、検証環境だと通らない billsテーブルのrecordデータ作成 UPDATE bills SELECT FROM bills APIリクエストbody $bill->price * $bill->tax_percentage INSERT INTO payments 既存コード修正イメージ $bills = BillRepository->findByChildIds() $bill->priceTotal() 請求額の変更が反映されない！変更・確定の保存は成功している

確定した請求情報を保存保存した請求情報を再取得請求情報を受信請求額（消費税）を計算請求額を入金管理に登録原因 billsテーブルのrecordデータ作成 UPDATE bills SELECT FROM bills APIリクエストbody $bill->price * $bill->tax_percentage INSERT INTO payments 既存コード修正イメージ $bills = BillRepository->findByChildIds() $bill->priceTotal() 全体が１トランザクション WriterDBに接続 SELECTクエリの場合は自動でReaderDBに接続トランザクションの途中なので再取得結果（ReaderDB）には変更が反映されていない

63 CONFIDENTIAL - © 2022 CoDMON Inc. 63 • 既存コードとリポジトリ実装で、
トランザクション（DBClientインスタンス）が別になっていた →同一のトランザクションを使うように修正した • ローカル環境はDBとReader/Writerが同一コンテナだった →ローカル環境もReader/Writeを分けて不具合を検出可能とした１つのAPIの責務が大きいどうしたか

65 CONFIDENTIAL - © 2022 CoDMON Inc. 65 １つのAPIの責務が大きいなぜバグを作り込んでしまったのか？
• トランザクション範囲の確認不足？ • フレームワークの仕様の確認不足？それはそう　でも、そもそも • トランザクション範囲が広すぎでは？ • １API、１ユースケースの責務が大きすぎでは？ ※ここで言う「ユースケース」は、実装文脈の「アプリケーションサービス」

確定した請求情報を保存保存した請求情報を再取得請求情報を受信請求額を計算請求額を入金管理に登録トランザクション範囲を再考する請求情報を変更・確定する確定請求額を入金管理に登録するこの境界線でトランザクション範囲は分けられるはず別の集約集約

67 CONFIDENTIAL - © 2022 CoDMON Inc. 67 １つのAPIの責務が大きい API・ユースケースの責務を再考する
ユースケースを前半と後半で２つに分けたいただし、 • ユーザ操作は１アクションのままにしたい • フロントからのAPIリクエストも、１つのままにしたい請求情報を変更・確定する確定請求額を入金管理に登録する入金管理は別コンテキストになりそう

68 CONFIDENTIAL - © 2022 CoDMON Inc. 68 １つのAPIの責務が大きい DDDの「ドメインイベント」の考え方を取り入れてみる
「ドメインイベント」とは「ドメインエキスパートが気にかける、何かの出来事」ドメインエキスパートの話の中に出てくるフレーズ • 「・・・するときに、」 • 「もしそうなったら、・・・」 • 「・・・の場合は、私に知らせてほしい」「・・・の場合は、通知してほしい」 • 「・・・が発生したときに」「実践ドメイン駆動設計」より抜粋

69 CONFIDENTIAL - © 2022 CoDMON Inc. 69 １つのAPIの責務が大きい DDDの「ドメインイベント」の考え方を取り入れてみる
請求情報を変更・確定する確定請求額を入金管理に登録する < event > 請求が確定したドメインイベントを介して、２つのユースケースを繋げる ObserverパターンまたはMessaging Serviceを介してイベント連携する 1つのユースケースの責務を小さく保ちつつ、ユーザ操作やAPI呼び出しも最小限に抑えることが可能 Publish Subscribe

73 CONFIDENTIAL - © 2022 CoDMON Inc. 73 思った以上に重複が多い無事にインボイス対応を終えた後
私は、決済基盤を新規開発する別チームに異動しましたこのチームでは、Kotlinで新しいマイクロサービスを開発していますそんなある日のこと「今日やるストーリーではこの画面を作ろう！」また消費税計算つくるの？今度はKotlinで？開発中の画面です

74 CONFIDENTIAL - © 2022 CoDMON Inc. 74 思った以上に重複が多い •
請求管理機能で消費税計算の修正を、長い時間をかけてやっていた • 他の機能でもそれぞれ消費税計算を実装している ↓ でも、ユーザ価値はなにも増えてない振り返れば

76 CONFIDENTIAL - © 2022 CoDMON Inc. 76 思った以上に重複が多い DDDの「汎用サブドメイン」の考え方を取り入れてみる
「汎用サブドメイン」とは設計中のプロジェクトにとって動機となっていない、高凝集のサブドメインを識別すること。そうしたサブドメインから汎用的なモデルを括り出して、別のモジュールに入れること。その中に特化した要素を一切残してはならない。いったん分離したら、その部分に対して継続される開発の優先順位をコアドメインより下げ、その作業にコアとなる開発者を割り当てるのを避けること（そこから得られるドメインについての知識はほとんどないからだ）。「エリック・エヴァンスのドメイン駆動設計」より抜粋

77 CONFIDENTIAL - © 2022 CoDMON Inc. 77 思った以上に重複が多い請求管理機能の価値とは？
多様な保育料形態への対応複雑な延長保育料の自動計算各種保育実績と連動した請求額計算請求管理機能が提供したい価値消費税計算必要だが本質ではない固有性はないコアドメイン汎用サブドメイン

78 CONFIDENTIAL - © 2022 CoDMON Inc. 78 思った以上に重複が多い汎用サブドメインの対応方法
「エリック・エヴァンスのドメイン駆動設計」より • 選択肢１：既製品による解決 • 選択肢２：公表されている設計やモデル • 選択肢３：実装のアウトソーシング • 選択肢４：自社での実装汎用サブドメインに力をかけずコアドメインに注力したい

イベントストーミングによるモデリングを取り入れてみる成瀬さんにワークショップを実施いただき、チャレンジ中弊社テックブログ記事：https://tech.codmon.com/entry/2024/03/19/204440

Amazon API Gateway Microservice Amazon EventBridge Event Bus Rule Rule Rule API Destination Rule API Destination API Destination Monolith UseCase Aggregate Publisher Forwarder Subscriber Controller Microservice create update delete publish event イベント駆動のモデルに適したアーキテクチャを検討中モノリスとマイクロサービスを繋ぐMessaging Serviceの案

汎用サブドメインの対応方法「エリック・エヴァンスのドメイン駆動設計」より • 選択肢１：既製品による解決 • 選択肢２：公表されている設計やモデル • 選択肢３：実装のアウトソーシング • 選択肢４：自社での実装汎用サブドメインに力をかけずコアドメインに注力したいまずは社内で公表されたモデルのドキュメントを用意するモノリス・マイクロサービスで複数のプログラミング言語が混在

91 最後に

92 CONFIDENTIAL - © 2022 CoDMON Inc. 92 改めて振り返ると DDDのパターンを使用して、レガシーコードのリファクタリングを行なった
　↓ レガシーコードの課題が浮き彫りになった　↓ 浮き彫りになった課題の解決策もまた、DDDの中にあった　↓ DDDの理解が深まり、新規開発でもより良い設計ができるようになった

93 CONFIDENTIAL - © 2022 CoDMON Inc. 93 改めて振り返ると •
自分たちが当事者である課題 • 仮定でなく、現実に起きている課題 • ビジネスとともに成長してきた複雑な課題リアルな設計課題とはレガシーコードはリアルな設計課題の宝庫 • 解決したい課題が実感しやすい • 設計パターンの必要性や使い所がわかる • 設計パターンを実際に開発現場で試せる読書や演習と比べて ↓

94 CONFIDENTIAL - © 2022 CoDMON Inc. 94 つまりリポジトリ
エンティティ値オブジェクトレガシーコード負債との闘いリアルな設計課題設計課題の解決策を探る新たな武器を得て再度潜入初期装備集約ドメインイベント汎用サブドメインレガシーコードのリファクタリングは「宝探し」

95 楽しそうじゃないですか？

96 ちなみに

97 コドモン採用ページ開発ブログコドモンでは一緒に働きたい仲間を募集しています！

98 ご清聴ありがとうございました！

DDDでレガシーコードに立ち向かうリアル / Reality of confronting ...

DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD

More Decks by コドモン開発チーム

Featured

Transcript