「システム稼働の安全性を担保する」＋「システムの境界を明確にする」、4つのステップから成るロードマップとは
この仮説に基づき、深見氏のチームではモジュラーモノリスへの移行に向けた4つのステップからなるロードマップを策定した。これは単なるコードの書き換えではなく、安全性を担保しながら徐々にシステムの境界を明らかにしていく綿密なエンジニアリングのプロセスだ。
1つ目のステップは、単体テストの拡充によるリファクタリング基盤の強化である。既存のコードベースには、システムを安全に変更するために不可欠なテストコードが決定的に不足していた。
そこで、ビジネスロジックの入り口となるエンドポイントからデータベースのアクセスに至るまでを一気通貫で網羅するテストケースの作成に着手。深見氏らは、ソースコードをステップバイステップでデバッグ実行しながら、処理の流れと仕様を解読し、外部システムへの依存などコントロールできない部分は随時モック化しながら、現在のシステムの振る舞いを固定化する「ベストケース」を作り上げていった。
手動でのカバレッジ向上に加え、AIの力も活用して未到達の条件分岐を埋めていくなど、現代的な手法も駆使してリファクタリングのための強固な安全網を構築したのである。
続いて、2つ目のステップは「正しい置き場へのコード移動と境界線の設定」。強固なテスト基盤が整備された後は、システム内に散り散りになっている処理を、業務上の正しい境界線の内側に物理的・論理的に整理していく作業を進めた。
外部からのAPIリクエストを受け付ける部分はプレゼンテーション層へ、ビジネスロジックはアプリケーション層のユースケースクラスへと移動。データベースへのアクセスを担うDAO層については、移動が困難な構成であったため、「リポジトリ」という名前のクラスを新たに作成してラップし、所属する業務領域を明示的に宣言するアプローチをとった。
さらに、他ドメインからの呼び出しを整理するため、「Expose」という外部公開用のパッケージを定め、そこにアクセスを集中させる設計を採用。これにより、将来的なマイクロサービス化を見据えたAPIエンドポイントの原型をシステム内部に作り上げたのだ。
そして、ステップの3つ目が「DDDの文脈を用いた業務知識の集約」だ。ドメイン駆動設計（DDD）の文脈を取り入れ、引かれた境界線の中に「業務知識を集約」していく土台作りを行った。
最初から完全なモデリングを目指すのではなく、機械的に判断できる部分から着手したのが実践的なポイントだ。あちこちに散らばって定義されていたプリミティブな変数を「バリューオブジェクト」として再定義し、影響範囲が読めない無数のリスト操作を「ファーストクラスコレクション」という専用クラスにカプセル化して処理を集約した。
「まずはその業務知識を集約するための土台を作り上げていくということを目的に、まずここまでの土台を作り上げよう」という深見氏の言葉通り、これはシステムの振る舞いを読み解きやすくするための極めて効果的な戦術であった。
そして、最後のステップが「隠れビジネスロジックの統合」だ。これは、楽天e-NAVI固有の課題への対処である。通信の通り道に過ぎないはずのAPIの受け口層に紛れ込んでいた「隠れビジネスロジック」を発見したチームは、これらをステップ1と同様にテストで厳重に保護した上で、本来あるべきビジネスロジックの層へと集約し、関連する機能を1つの整頓されたモジュールへと統合する作業を行った。
