1 © 2012-2025 BASE, Inc. 技術的負債への向き合い PHP編 2025/5/8 #php_over_10years リアーキテクチャの現場で向き合う 既存サービスの読み解きと設計判断 

2 © 2012-2025 BASE, Inc. 自己紹介 宮村 幸宏 ● BASE株式会社 ● 所属：BASE / Product Dev / Product Dev 02 / Module development ● 役割：Engineering Program Manager ● 現在の仕事 ○ バックエンド開発 ○ 注文管理モジュールを中心にリアーキテクチャや新規機能開発を担当 ● 好きなこと ○ ドメイン駆動設計 ○ チーム開発・アジャイル 

3 © 2012-2025 BASE, Inc. はじめに 本日の内容 ● BASEのリアーキテクチャプロジェクトの事例紹介 ● 具体的なモジュール開発の進め方 ○ 「負債」を抱えたシステムの読み解き ○ 現場での設計判断の経験 

4 © 2012-2025 BASE, Inc. BASEのリアーキテクチャ プロジェクト事例紹介 

5 © 2012-2025 BASE, Inc. BASEでの技術的負債への取り組み ● そもそも「技術的負債」とは？ ○ Ward Cunningham の「負債」のメタファー（1992） ■ 借りることは悪くない、返さないと利子がつく ■ 「コードは今の理解の写し身」理解を更新しないと負債になる ■ 「借りる」の判断に関する言及 ○ 当初は「負債」と表現していたものが、後にコミュニティを中心に 「技術的負債」という表現で議論が広まっていった ■ https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor ● 我々は負債を返さなければならない ○ 創業（2012）→リアーキテクチャプロジェクトの開始（2020） 

6 © 2012-2025 BASE, Inc. BASEのリアーキテクチャ ● モジュラーモノリスを採用した新しいコードベースへの書き換え ○ ストラングラーパターンによる移行 ● OOP、DDD、クリーンアーキテクチャ等を活用 ● 詳しくは下記をご覧ください ○ https://speakerdeck.com/nazonohito51/base-rearchitecturing ○ https://speakerdeck.com/panda_program/base-modular-monolith 注文管理 Monolith カート 商品管理 ・ ・ ・ 

7 © 2012-2025 BASE, Inc. 具体的なモジュール開発の 進め方 

8 © 2012-2025 BASE, Inc. どのように設計を進めていくか 1. 現状の（負債を抱えた）コードの理解 2. 理想のコードの検討 3. 現実的に書くべきコードの判断 ● リアーキテクチャでは負債を抱えたコードを消すことが前提になるの で、現状理解がより重要（完全理解が必要） ● 新しいアーキテクチャはこれからの寿命が長いことを期待されるので、 現実的でありながらより理想を目指すことが求められる 

9 © 2012-2025 BASE, Inc. 現状のコードの理解は難しい ● 難しい… ○ 「なぜこうなっているか」がわからないコード ○ 一時的な施策や対応で使われていたコード ○ プロダクト仕様にはないが（誰かの）運用のためのコード ● 基本的には地道にやっていく ○ 普段から社内のいろいろなことを知っておく ○ 先入観を捨ててコードの違和感に向き合う ○ 未知の謎を見つけたら祝う💎 

10 © 2012-2025 BASE, Inc. 理想のコードの検討 ● DDDプラクティスの実践 ○ ドメインモデリング、イベントストーミング ○ サービスに関する仕様・運用・業務のあらゆる知識を理解する 注文の状態変更 売上計上 メール通知 不正対策 etc. 注文管理 店舗管理 売上管理 境界づけられたコンテキスト間の インタラクション 大きなトランザクションスクリプト 

11 © 2012-2025 BASE, Inc. ドメインモデリング ● 以下のようなことを往復しながら理解を進める ○ コードとかDBとかが出てこない業務整理 ○ 集約の定義 ○ ルールや付加情報の書き出し ○ ライフサイクルの整理 ○ 既存のワークフローを分解し、オブジェクト群の操作に捉え直し ● ホワイトボードは FigJamを使用 ● 成果物としての「ドメインモデル図」を残すことよりも、 「ドメインモデリング」によってメンバーの理解が深まることを重視 

12 © 2012-2025 BASE, Inc. イベントストーミングの様子 

13 © 2012-2025 BASE, Inc. 理想のコードの検討 ● DDDプラクティスの実践 ○ ドメインモデリング、イベントストーミング ○ サービスに関する仕様・運用・業務のあらゆる知識を理解する ● 社内の知識の探索 ○ 施策や障害対応などの履歴からコードの意図を探る ● git blame の活用 ○ 「いつ、なぜ書かれたか」を知るための道具 現在のサービス理解がコードに反映されたもの＝理想 と考えたときに、必要だったことは現状を正しく理解することでした 

14 © 2012-2025 BASE, Inc. 現実的に書くべきコードの判断 ● アーキテクチャは「こういう場合にはこう作れる」という部品を提供 ● 今がどういう場合なのかを判断するのは機能開発チームの役割 実際の例 ● モジュールの境界をどう定めるか ○ 対象の自分のモジュールにおける位置づけだけでなく、隣接モジュー ルに配置する場合の妥当性の検討が必要 ● トランザクション範囲をどこまで変えられるか ○ モジュラモノリスを採用したため、現行の挙動を維持することが可能 ○ 可能な範囲で一部の処理を非同期化したが、相変わらずデータベース トランザクションに委ねているところも多い 

15 © 2012-2025 BASE, Inc. どこまでやるべきか？と悩んだとき ● 今後の機能拡張が予想される領域であればあるほど、負債が返済されて いる価値が高い ● 逆にほとんど変更がないことが予想される場合、必要以上の理想の追求 はリターンが得られない可能性も ○ 「技術的に妥協した」のではなく「より重要なものに取り組めた」の だと、前向きに意思決定していく 

16 © 2012-2025 BASE, Inc. 本日のまとめ ● リアーキテクチャのような技術的負債への取り組みにおいて、アーキテ クチャ選定は最初の大きな意思決定ですが、具体的にモジュールを作っ ていく中での意思決定も重要です ● 注文管理モジュールのリアーキテクチャでは、良いコードを書くために 現状の仕様の読み解きと整理が重要でした。そのためにDDDなどのプラ クティスを活用しました ● リアーキテクチャ後の設計においては、読み解いた現状のシステムの理 解を素直に反映させることを最優先しながら、現状の制約や今後の拡張 予定を見据えて、現実的な選択肢を前向きに意思決定してきたいです 

17 © 2012-2025 BASE, Inc. おわり ご清聴ありがとうございました