リアーキテクチャの現場で向き合う 既存サービスの読み解きと設計判断

Transcript

1. 1 © 2012-2025 BASE, Inc. 技術的負債への向き合い PHP編 2025/5/8 #php_over_10years リアーキテクチャの現場で向き合う 既存サービスの読み解きと設計判断
2. 2 © 2012-2025 BASE, Inc. 自己紹介 宮村 幸宏 • BASE株式会社 • 所属：BASE / Product Dev / Product Dev 02 / Module development • 役割：Engineering Program Manager • 現在の仕事 ◦ バックエンド開発 ◦ 注文管理モジュールを中心にリアーキテクチャや新規機能開発を担当 • 好きなこと ◦ ドメイン駆動設計 ◦ チーム開発・アジャイル
3. 3 © 2012-2025 BASE, Inc. はじめに 本日の内容 • BASEのリアーキテクチャプロジェクトの事例紹介 • 具体的なモジュール開発の進め方 ◦ 「負債」を抱えたシステムの読み解き ◦ 現場での設計判断の経験
4. 4 © 2012-2025 BASE, Inc. BASEのリアーキテクチャ プロジェクト事例紹介
5. 5 © 2012-2025 BASE, Inc. BASEでの技術的負債への取り組み • そもそも「技術的負債」とは？ ◦ Ward Cunningham の「負債」のメタファー（1992） ▪ 借りることは悪くない、返さないと利子がつく ▪ 「コードは今の理解の写し身」理解を更新しないと負債になる ▪ 「借りる」の判断に関する言及 ◦ 当初は「負債」と表現していたものが、後にコミュニティを中心に 「技術的負債」という表現で議論が広まっていった ▪ https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor • 我々は負債を返さなければならない ◦ 創業（2012）→リアーキテクチャプロジェクトの開始（2020）
6. 6 © 2012-2025 BASE, Inc. BASEのリアーキテクチャ • モジュラーモノリスを採用した新しいコードベースへの書き換え ◦ ストラングラーパターンによる移行 • OOP、DDD、クリーンアーキテクチャ等を活用 • 詳しくは下記をご覧ください ◦ https://speakerdeck.com/nazonohito51/base-rearchitecturing ◦ https://speakerdeck.com/panda_program/base-modular-monolith 注文管理 Monolith カート 商品管理 ・ ・ ・
7. 7 © 2012-2025 BASE, Inc. 具体的なモジュール開発の 進め方
8. 8 © 2012-2025 BASE, Inc. どのように設計を進めていくか 1. 現状の（負債を抱えた）コードの理解 2. 理想のコードの検討 3. 現実的に書くべきコードの判断 • リアーキテクチャでは負債を抱えたコードを消すことが前提になるの で、現状理解がより重要（完全理解が必要） • 新しいアーキテクチャはこれからの寿命が長いことを期待されるので、 現実的でありながらより理想を目指すことが求められる
9. 9 © 2012-2025 BASE, Inc. 現状のコードの理解は難しい • 難しい… ◦ 「なぜこうなっているか」がわからないコード ◦ 一時的な施策や対応で使われていたコード ◦ プロダクト仕様にはないが（誰かの）運用のためのコード • 基本的には地道にやっていく ◦ 普段から社内のいろいろなことを知っておく ◦ 先入観を捨ててコードの違和感に向き合う ◦ 未知の謎を見つけたら祝う💎
10. 10 © 2012-2025 BASE, Inc. 理想のコードの検討 • DDDプラクティスの実践 ◦ ドメインモデリング、イベントストーミング ◦ サービスに関する仕様・運用・業務のあらゆる知識を理解する 注文の状態変更 売上計上 メール通知 不正対策 etc. 注文管理 店舗管理 売上管理 境界づけられたコンテキスト間の インタラクション 大きなトランザクションスクリプト
11. 11 © 2012-2025 BASE, Inc. ドメインモデリング • 以下のようなことを往復しながら理解を進める ◦ コードとかDBとかが出てこない業務整理 ◦ 集約の定義 ◦ ルールや付加情報の書き出し ◦ ライフサイクルの整理 ◦ 既存のワークフローを分解し、オブジェクト群の操作に捉え直し • ホワイトボードは FigJamを使用 • 成果物としての「ドメインモデル図」を残すことよりも、 「ドメインモデリング」によってメンバーの理解が深まることを重視
12. 12 © 2012-2025 BASE, Inc. イベントストーミングの様子
13. 13 © 2012-2025 BASE, Inc. 理想のコードの検討 • DDDプラクティスの実践 ◦ ドメインモデリング、イベントストーミング ◦ サービスに関する仕様・運用・業務のあらゆる知識を理解する • 社内の知識の探索 ◦ 施策や障害対応などの履歴からコードの意図を探る • git blame の活用 ◦ 「いつ、なぜ書かれたか」を知るための道具 現在のサービス理解がコードに反映されたもの＝理想 と考えたときに、必要だったことは現状を正しく理解することでした
14. 14 © 2012-2025 BASE, Inc. 現実的に書くべきコードの判断 • アーキテクチャは「こういう場合にはこう作れる」という部品を提供 • 今がどういう場合なのかを判断するのは機能開発チームの役割 実際の例 • モジュールの境界をどう定めるか ◦ 対象の自分のモジュールにおける位置づけだけでなく、隣接モジュー ルに配置する場合の妥当性の検討が必要 • トランザクション範囲をどこまで変えられるか ◦ モジュラモノリスを採用したため、現行の挙動を維持することが可能 ◦ 可能な範囲で一部の処理を非同期化したが、相変わらずデータベース トランザクションに委ねているところも多い
15. 15 © 2012-2025 BASE, Inc. どこまでやるべきか？と悩んだとき • 今後の機能拡張が予想される領域であればあるほど、負債が返済されて いる価値が高い • 逆にほとんど変更がないことが予想される場合、必要以上の理想の追求 はリターンが得られない可能性も ◦ 「技術的に妥協した」のではなく「より重要なものに取り組めた」の だと、前向きに意思決定していく
16. 16 © 2012-2025 BASE, Inc. 本日のまとめ • リアーキテクチャのような技術的負債への取り組みにおいて、アーキテ クチャ選定は最初の大きな意思決定ですが、具体的にモジュールを作っ ていく中での意思決定も重要です • 注文管理モジュールのリアーキテクチャでは、良いコードを書くために 現状の仕様の読み解きと整理が重要でした。そのためにDDDなどのプラ クティスを活用しました • リアーキテクチャ後の設計においては、読み解いた現状のシステムの理 解を素直に反映させることを最優先しながら、現状の制約や今後の拡張 予定を見据えて、現実的な選択肢を前向きに意思決定してきたいです
17. 17 © 2012-2025 BASE, Inc. おわり ご清聴ありがとうございました