Module BoundaryはPublic API・Internal・Allowed Dependenciesで実体化する
Module Boundaryを単なるpackage/directory conventionにすると、時間とともに内部実装へのshortcut dependencyが増えやすい。境界をArchitectureとして機能させるには、少なくとも Public API、Internal implementation、Allowed Dependencies の3点を機械的に区別できることが望ましい。
Spring ModulithではModuleのbase packageが公開APIになり、sub-packageは原則internalとして扱われる。必要な追加公開面はNamed Interfaceとして宣言でき、allowedDependencies で参照可能Moduleを限定できる。さらにverificationによってcycleやinternal accessを検出できる。
Application Operationとの関係では、「どのModuleがOperationをownerするか」を明示することが重要になる。Transport AdapterはModuleのinternal repositoryを直接呼ばず、Module Public APIとして公開されたOperationへ入る。
Transport → Module Public API → internal use case/domain/repository
↑
allowed dependencies
この境界はAI coding agentにとっても意味を持ちうる。Public APIとdependency ruleが明確なら、「変更対象Moduleの中をまず探索し、必要になった時だけ隣接Moduleへ広げる」という探索戦略を取りやすい。Module BoundaryはAI Coding AgentのContext Boundaryとしても機能しうる でこの仮説を扱う。
ただし境界をinterface fileの量で測るべきではない。すべてのclass/functionへinterfaceを作るとNavigationが悪化し、人間にもAIにも間接参照が増える。Module Boundaryは外から触ってよい面を狭めるためのもので、内部までClean Architecture風の層へ細分化することとは別問題である。