Resource IdentityはURLそのものではなくDomain上の安定した参照として考える
ResourceをApplication Coreへ持ち込むなら、まずTransport上のlocationとDomain上のidentityを分けたい。Google AIP-122はResourceにcanonicalなnameを与え、publishers/123/books/les-miserables のようなresource nameをAPI利用者が保存できる安定した参照として扱う。必要ならservice名を付けたfull resource nameも定義する。
ここから得られる設計上の示唆は、Resource Identityを HTTP path == identity と固定しないことにある。Application内部では例えば Project(projectID)、Document(documentID) のような型付きIdentityを持ち、REST adapterはそれをpath parameterから解決し、MCP adapterはtool argumentやresource URIから解決し、Jobはmessage payloadから解決できる。入口が変わっても「どのDomain objectを指しているか」は同じである。
MCPにもResourceという語があるが、MCP 2026-07-28仕様のResourceは「modelへcontext/dataを提供するserver feature」で、URIで一意に識別される。これはDomain Resourceと必ずしも同一ではない。たとえばDomain上のDocumentをMCP Resourceとして公開することはできるが、公開表現とDomain Identityを一対一に固定する必要はない。
Identityを抽象化しすぎると Resource{Type, ID} のようなGeneric Resourceへ流れやすい。その場合、型固有の不変条件や親子関係が失われる危険がある。Generic Resourceへ寄せすぎるとDomain Semanticsが失われる でこの反論を扱う。