| 類型 | 職責範圍 | 典型範例 |
|---|---|---|
| 應用邏輯 | 協調流程、事務邊界、安全驗證 | 訂單建立流程、權限檢查 |
| 領域邏輯 | 核心業務規則、不變條件、實體行為 | 庫存扣減規則、金額計算邏輯 |
表示層 → 業務邏輯層 → 資料存取層
將業務邏輯層拆分為：表示層 → 服務層 → 領域層 → 資料存取層
資料存取層需了解領域模型，產生雙向依賴：
| 方案 | 代表專案 | 評價 |
|---|---|---|
| 領域模型置於共享層 | PetShop | 業務層名不副實、領域模型退化為資料模型、引入更多依賴、資料驅動思維 |
| 資料存取介面定義於業務層 | NopCommerce | 雖採用介面隔離與 Repository 命名，但非真正 DDD、未將技術依賴完全從業務層分離 |
結構：表示層 → 應用層 → 領域層 → 基礎設施層
優點：具體技術實作從領域分離，基礎設施層復用價值提升
缺點：基礎設施層未細分共享/實現，Repository 實作產生反向依賴，多專案方案需介面隔離
特徵：基礎設施層同時具備共享層與實現層特性
優點：形式上達成領域核心，解決 Repository 無法引用領域模型尷尬
缺點：未明確區分共享與實現概念
核心突破：徹底應用依賴倒置原則，所有外層依賴內層抽象
優點：真正以領域為核心，無需在服務層再次適配
缺點：依賴倒置過度應用，多專案方案產生命名空間層面雙向依賴，基礎設施層復用價值降低
改進建議：調換用戶介面層與基礎設施層位置，視需求引入共享層
架構演進的本質，是對「關注點分離」與「依賴倒置」原則的不斷深化應用。選擇何種架構，應基於團隊能力、專案複雜度與長期演進需求綜合判斷，而非盲目追求最新模式。
