Domain AuthorizationはOperationが具体Resourceへ作用してよいかを判定する
Domain Authorizationは、認証済みPrincipalがApplication Operationを 具体的なDomain Resourceに対して実行してよいか を判定する層として考えられる。Transport Authorizationがtoken・audience・scopeを扱うのに対し、こちらはownership、membership、resource state、delegationなどApplication固有の規則を扱う。
Cedarはbusiness logicからauthorization logicを分離し、Operation実行前にauthorizerへ問い合わせる構成を説明している。OpenFGAやSpiceDBも、applicationがresourceとsubjectを指定してpermission/relationshipを問い合わせる。既存ノート 認可をルーティングではなくメソッド境界に置く のように、この境界をrouteではなくmethod/operationへ置くことができる。
Application Operation
├─ resolve Resource
├─ authorize(P, A, R, C)
└─ execute Domain logic
この配置の利点は、HTTP、MCP、Jobなど複数Transportが同じ業務認可を共有できることにある。また「どのOperationがどのPermissionを要求するか」をApplication Catalogへ記述しやすい。
一方で、Domain invariantとAuthorization policyの境界は常に明確ではない。例えば「確定済みInvoiceは編集不可」は、誰であっても成立するDomain invariantならauthorizerよりDomain modelで拒否する方が自然である。「Finance roleなら確定前Invoiceを編集可」はauthorizationである。すべての拒否条件をpolicy engineへ移すとDomain semanticsが散る。
したがってDomain AuthorizationはBusiness Logicそのものを外出しする層ではなく、authorityに依存する判断をOperation boundaryへ集約する仕組みと捉えるのがよい。