J2EE 分層架構設計反模式與正規軍規：從「表驅動」到「領域驅動」的轉型

許多專案號稱「分層架構」，實則是「表驅動開發」：一張表對應一個 DAO、一個 Domain、一個 Service，導致 Service 接口膨脹、Action 層重複調用、事務控制混亂。本文對比反模式與正規設計，闡述領域活動聚合 DAO、Service 組合領域活動、事務上收到 Service 層的核心原則，並探討去 DAO 化的領域模型驅動設計（DDD）利弊權衡。

典型反模式：表驅動開發

Table User  →  UserDAO  →  UserDomain  →  UserService(CURD×N)
Table Order →  OrderDAO →  OrderDomain →  OrderService(CURD×N)
// Service 接口爆炸，Action 中反復調用多個 Service 方法拼湊業務

正規分層原則

1. 依賴單向向下：Presentation → Service → Domain Activity → DAO
2. 同層不互調（工具方法除外）
3. 從 Service 接口出發設計，而非從資料庫表出發
4. 領域活動聚合 DAO：一個轉賬業務 = 兩個領域活動（扣款/入賬）+ 多個 DAO 操作
5. 事務邊界在 Service 層控制
6. 接口職責單一、邊界清晰

DDD 風格：去 DAO 化

將 DAO 與 Domain 合併為 Activity（聚合根），Service 直接依賴 Activity。優點：設計意圖清晰、避免貧血模型；缺點：持久化技術變更波及 Activity 代碼。綜合權衡：持久化技術變更極少見，收益大於成本。

Service 粒度控制

一個業務模組對應一個 Service，接口數量由上而下逐層遞增。拒絕「一表一 Service」，擁抱「一業務一 Service」。

血淚教訓

某團隊 30+ 表、一表一 DAO/Service，性能極差頻繁宕機。根因非框架/資料庫/硬體，純屬拙劣設計。架構即命脈，容不得馬虎。