Java 專案常見認知盲區：架構腐化、ORM 濫用與 DDD 破局之道

前言：技術不再是瓶頸，認知才是

越來越多團隊引入 Java、Spring、Hibernate 等主流技術棧，卻發現系統上線後效能低落、維護成本飆升、甚至頻繁當機。根因不在框架本身，而在於團隊缺乏 物件導向 (OO) 設計思維 與 領域驅動設計 (DDD) 的架構落地能力。本文剖析四大核心誤區，並給出破局路徑。

誤區一：功能至上，架構腐化——軟體的生命力在於可演進性

許多專案初期為趕進度，堆疊功能、忽略分層邊界。結果：

• 新增功能需修改十幾個類，牽一髮動全身
• 技術債累積至無法重構，只能重寫
• 資深工程師離職帶走失敗經驗，新人重蹈覆轍

正確觀點：靈活可擴展的基礎架構優先於完整功能。好的架構讓功能新增只是「時間與工作量」問題；壞架構讓系統走上死路。開源框架（如 OFBiz、Compiere）若缺乏領域建模，同樣淪為「擴展性極差的成品軟體」。

誤區二：存儲過程與複雜 SQL 綁架業務邏輯——資料庫不是業務核心

效能迷思

「存儲過程解決效能」是危險的短視行為：將業務邏輯下沉資料庫，導致應用伺服器淪為單純傳輸層，喪失分散式運算、叢集擴展能力。面對高併發網路流量，單點資料庫註定成為瓶頸。

分層違背

三層架構中，持久層職責是「保管領域物件」，而非「執行業務組合」。要求持久層「把水果切好裝盤端上來」，違背單一職責原則。

反向腐蝕

另一極端：業務層滿是資料表欄位名、DTO 滿天飛，領域模型貧血化。PoEAA 原則：除持久層外，不應出現資料表結構痕跡。

折中建議

依 Evans DDD 理論，將 SQL/存儲過程視為 Specification 規則一部分，而非業務邏輯主體。

誤區三：Hibernate 效能差？錯在領域建模缺失

典型失敗模式：

// 為避免 LazyInitializationException，全域關閉 lazy loading
@ManyToOne(fetch = FetchType.EAGER)  // 導致載入單筆資料連帶撈全庫
private Department department;

根因：以資料表為中心設計物件模型，而非以領域邊界劃分聚合。Hibernate 設計目標是持久化 豐富領域模型，若物件只是 DTO，ORM 註解反成負擔。

解決路徑：

1. 先做 DDD 領域建模：識別聚合根、值物件、領域事件，建立通用語言。
2. 依領域模型設計物件關聯，降低關聯複雜度（單向導航、聚合邊界隔離）。
3. 再映射至資料表，接受「物件與關係阻抗失配」的必要妥協。

若團隊不具備領域建模能力，No ORM 可能是更簡單的選擇。

誤區四：Spring 分層矛盾——業務層缺乏 Session 抽象

購物車案例：業務邏輯需維護會話狀態，但 Spring 業務層無法存取 HttpSession，迫使「將購物車存入 HttpSession」的邏輯下沉到表現層，導致分層架構崩塌。

DDD 視角的解法：

• 在領域層引入 領域服務 或 應用服務 協調會話狀態。
• 定義 SessionContext 介面，由表現層實作（委派給 HttpSession），業務層依賴抽象而非具體實作。
• 進一步劃分：應用層 → 領域層 → 基礎設施層，各層職責單一、依賴倒置。

DDD：不只是理論，是實戰經驗的萃取

Eric Evans 《領域驅動設計》開篇即強調分層架構。DDD 提供：

• 框架選型標準：無法支援分層架構的框架，果斷捨棄。
• 業務層再細分：領域層（核心業務規則）、應用層（用例編排）、基礎設施層（技術實作）。
• 戰術建模工具：實體、值物件、聚合、工廠、倉儲、領域事件。

DDD 非銀彈，但能幫團隊跳出「技術細節迷霧」，找回架構決策的根本依據。

總結：從「會用框架」到「懂架構」

Java 生態工具再豐富，缺了 OO 思維與 DDD 落地，終究是「磨刀不誤砍柴工」——先磨好刀（架構思維），再砍柴（寫代碼）。