OperationはTransportから独立したApplication Capabilityとして置ける
ここでいうOperationは、Applicationが外部または他Moduleに提供する 意味のあるCapability を指す。CreateProject、ArchiveProject、SearchDocuments のような単位であり、HTTP methodやMCP method名そのものではない。
Google AIP-130はAPI methodをserviceがconsumerのために実行できるoperationとして定義し、標準Methodとcustom methodを区別する。GoaもServiceのMethodを先に設計し、そのMethodへHTTP transportを割り当てる構造を取る。Goa-AIでは同じservice methodをMCP Toolへ結び付ける設計も可能で、CapabilityとTransport mappingを別レイヤで表す実例になっている。
Application Architectureとしては、HTTP POST /projects/{id}:archive、MCP tools/call archive_project、定期Job、CLI project archive がすべて同じ ArchiveProject Operationへ到達できる構造を考えられる。
HTTP / MCP / Job / CLI
↓
ArchiveProject
↓
Authorization + Module
利点は、TransportごとのhandlerがBusiness Logicのownership boundaryにならないことだ。一方、すべてをOperation objectへ形式化すると、小規模なCRUDまで間接層が増える。単純なApplicationではhandler function自体をOperationとして扱い、追加のinterfaceやdispatcherを作らない方が局所性が高い場合もある。CommandはHTTP Requestではなく状態変更の意図を表す や Command BusはOperation dispatchの選択肢でありArchitectureの前提ではない は、Operationをさらに形式化する場合の選択肢であって必須条件ではない。