😽
ドメインの権限管理が適切に適用されているか？
ドメインの権限管理が適切に設計されているか？
背景・概要
業務において誰が何をできるか/できないかは重要な制約事項であり、実装の初期から考慮しておかないと後のセキュリティ事故・バグ・混乱の原因となる。
ドメイン層で表現すべきか、アプリケーション層で制御すべきかの切り分けも重要
例
- Task.canApprove(user: User): Boolean のような問いかけ型のメソッドは設けず、Task.approve(user: User)内で権限制御するか、複雑な場合はTaskApprovalPolicyのようなポリシードメインを作成する
- ロールや権限はEnum/DB/sealed interfaceなどで管理し、表示・ユーザー操作の制御は画面やAPIで行う
- 各ユースケース（ApplicationService）では権限チェックを明示的に記述して曖昧さを排除する
よくある失敗例
- 「一部の画面では表示されるが、操作はできない」など中途半端な制御になる
- フロント側でしか制御されておらず、APIを直接叩けば何でもできてしまう状態
- 権限制御がコードベースのあちこちに散らばっており、ロール追加や変更時にミスが頻発
FAQ
Q. 権限チェックはユースケースかドメインか？
A. ケースバイケース。ドメインでは「このデータに対して誰が何をできるか」を制御し、ユースケースでは「業務上その操作が可能か」を判断するのが無難と思われる
Q. 権限のソースはEnumかDBかどこにおく？
A. 小規模ならEnum、大規模ならDBやStrategy(Policy)パターンを使って柔軟に実装できる
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🏷️ドメイン
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion