Application CatalogはArchitectureをAIとToolが読めるMachine-readable Dataにする
Applicationの規模が大きくなると、ArchitectureをREADMEや人間の記憶だけに置くのではなく、Machine-readable Application Catalog として持つ価値が出てくる。
例えばCatalogに次を記述する。
Module: documents
Public Operations: CreateDocument, SearchDocuments, ShareDocument
Owned Resources: Document, Folder
Required Permissions: document.create, document.search, document.share
Transports: HTTP, MCP
Allowed Dependencies: identity, storage
これは単なるAPI schemaより広く、Module ownershipとdependencyまで含むarchitecture metadataである。Spring Modulithは実行可能なApplication Module modelを構築し、そこからcomponent diagramやApplication Module Canvasを生成できる。Goa-AIもdesignからauthoritativeなtool catalog、typed identifiers、payload/result schemaを生成し、plannerやUI、外部orchestratorが利用できる。
AI coding agentにとっては、このCatalogをrepository retrievalの入口にできる。自然言語taskからModule/Operationを特定し、Public APIとallowed dependencyを辿ってcontextを狭める。Module BoundaryはAI Coding AgentのContext Boundaryとしても機能しうる の仮説を実装可能なdataへ落とす役割である。
ただしCatalogを手書きで二重管理すると必ずdriftする。理想はcode/design definitionから生成するか、CIでactual dependency graphと照合することだ。Spring Modulithのverification/documentationやGoa系のdesign-first code generationは、この方向の参考になる。
またCatalogに全symbolを入れると巨大なcode indexになり、本来のarchitecture summaryとしての価値を失う。載せるのはownership、public capability、resource、permission、dependency、transport mapping程度に絞り、詳細symbol searchは別indexへ任せる方がよい。