Generic Resourceへ寄せすぎるとDomain Semanticsが失われる
Resource IdentityやPermissionを共通化し始めると、Resource{Type, ID, Parent} のような万能表現を作りたくなる。しかしGeneric ResourceをApplication Coreの中心型にすると、Domainごとの差が消えやすい。
Project、Invoice、Document は同じ「IDを持つもの」でも、lifecycle、合法なOperation、不変条件、parent semantics、共有可能性が異なる。Google AIPのResource-oriented designも、すべてを一種類のResourceへ統合するのではなく、個別にnamed resourceを定義し、それぞれにMethodを与える。Cedar schemaやOpenFGA modelもResource/Objectのtypeを明示できる。
Generic Resourceが有効なのは、境界の共通形式としてである。例えばaudit log、authorization request、catalog、telemetryでは type + id に正規化すると横断処理しやすい。一方、Operation実装へ入った後までgeneric representationを引き回すと、switch resource.Type やdynamic castが増え、型が持てたはずの意味をruntimeへ戻してしまう。
したがって、
Boundary: ResourceRef{type, id}
↓ resolve
Core: ProjectID / DocumentID / InvoiceID
のように、境界でgeneric、Coreでspecificという二段構成が一つの妥協になる。
Authorization Graphにも同じ注意がある。graph store上ではobject typeを共通形式で扱えても、そのgraphをDomain hierarchyそのものだと思わない方がよい。Resource HierarchyはOwnershipやScopingを表せるが万能の認可Treeではない と Authorization GraphはResource Hierarchyとは別のRelationship Graphとして持つ を分ける理由でもある。
抽象化の目的は共通化ではなく、変更理由を分離することにある。Generic ResourceがDomain語彙を隠すなら、その抽象化は逆効果になりうる。