Localization CostはLayerと抽象化を増やすほど無視できなくなる
Localization Costとは、ある変更を行う前に 関連するcode・policy・schema・dependencyを見つけ、変更範囲を確定するためのコスト と捉えられる。これはruntime performanceではなく、開発者とcoding agentの探索コストである。
Repository-level coding研究はこのコストを直接扱っている。RepoCoderは必要情報がrepository内の複数fileへ散らばることを課題としretrievalを導入する。Agentlessはbug修正processの最初にfault localizationを独立phaseとして置く。つまりcontext windowが大きくなっても、「何を読むべきか」の問題は消えない。
Architectureでも同じことが起きる。例えば1つのOperationを変更するために、Controller、DTO、Mapper、UseCase interface、Interactor、Domain Service、Repository interface、Repository implementation、Policy adapterを順番に辿る必要があるなら、各Layerの分離利益と引き換えにLocalization Costが増える。
Vertical Sliceはこのコストを下げる方向の設計であり、Module Boundaryは探索範囲を絞る方向の設計である。一方、Moduleを細かくしすぎたりCommand Busを経由させすぎたりすると、呼び出し先の特定が難しくなる。
したがって「依存性逆転の数」「interfaceの数」ではなく、次のような指標を見る価値がある。
- 1 Operationの変更で触るfile/module数
- entrypointからbusiness ruleまでのnavigation hop数
- architecture metadataなしでownershipを特定できるか
- cross-module callが静的に追跡できるか
これは厳密に標準化されたsoftware metricではなく、設計レビュー用の概念である。重要なのは、Clean Architecture的な分離を増やすほど常に保守性が上がるとは限らない、という点にある。
Module BoundaryはAI Coding AgentのContext Boundaryとしても機能しうる と Vertical SliceはLayerではなくUse Caseの変更軸に沿ってコードをまとめる はLocalization Costを減らす別々のアプローチとして読める。