使用者管理架構設計：從單一模型到模組化抽象的演進思考

使用者管理是幾乎所有應用的核心子系統。本文從業務需求出發，分析單一模型/單表、多模型/多表、模組化抽象三種架構演進，探討擴充性與維護性的平衡。

使用者資料屬性分類

• 基礎屬性：帳號、密碼、Email、個人網址、手機、QQ、簡介、標籤
• 企業屬性：公司名稱、統編、營業執照、法人、聯絡人、職稱
• 金融屬性：開戶銀行、戶名、帳號（電商/金流必要）
• 認證方式：帳密、第三方（FB/Google/Line）、SSO、LDAP

架構演進三階段

階段 1：單一模型、單表儲存

所有屬性放入一個 User 類別，UserType 欄位區分類型。優點：模型單一、查詢簡單。缺點：大量 Null 欄位浪費空間、程式碼充滿 if (type == ...) 判斷、違反單一職責原則。

階段 2：多模型、多表儲存

依類型拆分：PersonalUser、EnterpriseUser 對應獨立資料表。優點：結構清晰、無空值浪費。缺點：

• 登入查詢需跨表（解決：建立資料庫 View 聯集）
• 新增共同屬性（如銀行帳戶）需修改多個模型/資料表
• 查詢單一類型時：用 Table 還是 View？決策困擾

階段 3：模組化抽象（組合大於繼承）

核心洩露：程式碼越貼近具體業務，復用性越低。採用組合模式：

public class User {
    public string Username { get; set; }
    public string PasswordHash { get; set; }
    public IProfile Profile { get; set; }      // 個人/企業資料模組
    public IAuthentication Auth { get; set; }  // 認證方式模組
    public IWallet Wallet { get; set; }        // 金融資訊模組（可選）
    public IRoles Roles { get; set; }          // 權限模組
}

• 各模組獨立開發、測試、部署
• 新增功能（如 OAuth）只需實作 IAuthentication 新類別
• 資料庫採用「核心表 + 擴充表」或 Document DB 彈性結構

設計原則總結

1. 識別變化點（使用者類型、認證方式、擴充屬性）
2. 將變化點抽象為介面，核心模型依賴介面而非實作
3. 採用組合/策略模式替代繼承體系
4. 資料層採用彈性結構支援動態擴充

此架構支援從簡單部落格到複雜電商平台的平滑演進。