Router ResponsibilityはResource Resolutionや業務認可まで抱え込まない方が拡張しやすい
小規模なWeb Applicationでは、Routerがpathをmatchし、path parameterからResourceを解決し、その場で認可し、handlerの配置がそのままApplication Structureを表す構成でも十分に機能する。
しかしこの結合は、同じOperationをMCP、Job、CLI、内部呼び出しから使い始めると再利用しにくくなる。Routerの基本責務を Transport上のrequestを適切なApplication Operationへdispatchすること に狭め、Resource ResolutionやDomain AuthorizationをOperation側または共有Application serviceへ移すと、入口ごとの差を小さくできる。
これは「Routerで認可してはいけない」という意味ではない。HTTP method、Origin、bearer token、route固有scopeなど、Transport固有のpolicyはRouter/middleware境界で扱う方が自然である。既存ノート 認可をルーティングではなくメソッド境界に置く が示すように、業務操作の認可はmethod boundaryへ置く選択肢もある。
また、path hierarchyがDomain hierarchyと一致する場合はRouterでparent resourceを先に解決する設計が効率的なこともある。パス階層を認可階層として使う のような方式を全面否定する必要はない。問題は、route treeしかApplication Structureを表現する場所がない状態である。
HTTP-onlyでrouteとuse caseが一対一の小規模Applicationなら、分離しすぎる方がLocalization Costを増やす。Router Responsibilityを狭めるのは、複数Transport・複雑な認可・Module ownershipが現れたときのスケーリング手段と考えるのがよい。