越來越多團隊引入 Java 技術棟樑，卻因缺乏物件導向架構思維訓練，陷入「功能堆砌、效能低落、維護噩夢」的泥沼。本文揭露當前 Java 開發中 5 大核心認知誤區，結合 DDD（領域驅動設計）、分層架構、ORM 最佳實踐，為您指明破局之道。
現象： 追求功能完整度超過架構延展性，以為「功能越多越好」，忽略「架構決定軟體能活多久」。
真相： 軟體有生命，靈活可擴展的基礎架構是生存根本。架構好，功能只是時間與工作量問題；架構爛，功能再全也裝不下未來變化。許多開源框架（如 OFBiz、Compiere）看似功能豐富，實則擴展性嚴重不足，類似盜版軟體——能跑不能改。
對策： 採用 分層架構（表現層/業務層/持久層），職責單一、依賴倒置。引入框架不等於架構好，關鍵在於如何用框架搭建業務系統。
現象： 將業務流程封裝在存儲過程，以為解決效能，實則製造單點瓶頸。
三大禍害：
正確定位： 持久層職責是保管領域物件，業務層只請求「歸還物件」，不要求「幫我組裝水果盤」。適量用 SQL/存儲過程作為 Specification（規約） 輔助查詢可接受，但不可成主導。
典型慘案： 關聯關係複雜 → 全域 lazy=false → 載入一筆資料拉起整張資料庫 → 系統癱瘓。
根因： 圍繞資料表建模，而非領域模型。Hibernate 設計目標是「物件模型持久化」，若先設計資料表再強行映射，必然扭曲物件模型，導致 DTO 滿天飛、效能與維護雙輸。
破局鑰匙 — DDD 領域建模：
錯誤流程： 先建表 → 再寫 Entity → 強行映射 → 物件模型變成資料表映射體（貧血模型）
正確流程： 領域建模 → 衍生持久化結構 → 由工具/手寫映射。資料庫是實作細節，不應主導設計。
痛點案例： 購物車屬業務邏輯，需跨請求保持狀態。Spring 業務層無 Session 支援 → 強行塞進 HttpSession → 業務層依賴 Web 層 API → 分層崩塌、測試困難、遷移受阻。
根因： Spring 定位為業務層容器，非 Web 框架，缺乏會話管理機制。
解法：
Eric Evans《領域驅動設計》非新理論，而是實戰經驗萃取。它回答：
DDD 將 PoEAA（企業應用架構模式）具體化、可操作化，獲 Martin Fowler 大力推薦。已延伸至 .NET 領域，證明其跨平台普適價值。國內早自 2005 年即有 JdonFramework 實踐，Java 生態始終走在先進思想落地前沿。
Java 專案成功與否，不在於用了什麼框架，而在於團隊是否擁有正確的架構認知與領域建模能力。從今天開始，為每一行代碼問一句：「這屬於哪一層？服務什麼業務不變量？」
