标签：#uidesign

We've all been there. Your first encounter with authorization looks something like this: if ( user . role === " ADMIN " ) { // allow access } It works. It's simple. It ships fast. And then, three months later, your application has grown, requirements have shifted, and you're staring at a codebase where authorization logic is scattered everywhere—APIs, services, UI components—like a puzzle that nobody remembers how to solve. The truth is: this approach doesn't scale. Not because it's inherently flawed, but because it conflates two very different concepts that should never be mixed. The Core Mistake: Confusing Identity with Capability Here's the problem we're actually trying to solve. As your application grows, you inevitably end up writing code like this: if ( user . role === " BRANCH_MANAGER " || user . role === " SYSTEM_ADMIN " ) { // allow access } Then a stakeholder asks: Can we create a hybrid role? Or: We need Auditors who can export reports but not edit records. And suddenly your role logic explodes into an unmaintainable mess. The fix isn't adding more conditions. The fix is understanding that roles and permissions answer fundamentally different questions. Roles Define Identity Roles are categories of users. Examples: SYSTEM_ADMIN CLIENT BRANCH_MANAGER AUDITOR Roles answer: Who is this user? They establish high-level authorization boundaries. Examples: Staff Portal vs Customer Portal Internal Admin Area vs Public Application Employee Features vs Client Features Think of roles as identity labels . Permissions Define Capability Permissions represent atomic actions. Examples: LOAN_APPROVE USER_DELETE REPORT_EXPORT ACCOUNT_EDIT Permissions answer: What can this user actually do? Your application should not constantly ask: What role are you? Instead, it should ask: Do you have permission to perform this action? Because: Users have Roles Roles contain Permissions Code checks Permissions That distinction changes everything. Always Decouple Identity from Capability T