バーティカルスライス設計（詳細）

エンジニア20名のHRテック企業。バーティカルスライスを採用したが、Handlerの書き方がエンジニアごとにバラバラで、あるHandlerは 300行、別のHandlerは 15行（ロジックがServiceに外出し）という状態になった。

実装ガイドラインを策定。「Handlerは 30〜100行」「DB操作はHandler内で直接」「100行超はドメインオブジェクトにロジックを移す」「共有ServiceはPipelineのみ」とルール化した。

コードレビューでの指摘が 60% 減少。新メンバーのオンボーディングでも「どこに何を書くか」の迷いが解消され、初PRまでの期間が 2週間 → 4日 に短縮された。

エンジニア35名の物流SaaS。レイヤードアーキテクチャ時代は、Serviceのユニットテスト（Mock多用）とE2Eテストの2極構成だった。Mockの保守コストが高く、E2Eは実行に 45分 かかっていた。

バーティカルスライス移行に合わせ、テスト戦略を「スライス単位の統合テスト中心」に変更。TestContainersでDBを起動し、APIリクエストからDB検証まで1テストで完結。Mockは外部APIのみに限定した。

テストのMock行数が 70% 減少。テスト実行時間は 45分 → 12分 に短縮（E2E削減分）。本番バグの発見率が テスト段階で78%（以前は 52%）に改善された。

エンジニア12名の教育プラットフォーム。Controllers/に 48ファイル、Services/に 35ファイル、Repositories/に 28ファイル が並ぶレイヤー別構成だった。「受講登録」機能の修正に3フォルダを行き来する必要があり、新メンバーが「どのファイルがどの機能か」を把握するのに 1週間 かかっていた。

Feature Folder構成に移行。Features/Enrollment/Register/にHandler・DTO・Validator・テストを集約。IDEのファイルツリーで機能の全体像が一目で把握できるようになった。

新メンバーが特定機能のコードを見つけるまでの時間が 平均15分 → 30秒 に短縮。「どこに書けばいいかわからない」というSlackの質問が月 12件 → 1件 に減少した。