軟體的生命力在於「可擴展架構」而非「功能堆砌」
許多團隊追求「功能完整」卻忽略基礎架構彈性。架構好，增功能只是時間與工作量問題；架構差，功能再全也無法承載未來變化。 開源框架（如 OFBiz、Compiere）看似功能豐富，實則擴展性不足，如同盜版軟體。
儲存程序與複雜 SQL 的陷阱
- 業務邏輯下沉資料庫：導致負載集中於 DB，中間層淪為傳聲筒，喪失分散式運算優勢。
- 分層錯位：持久層職責是「保管物件」，而非「處理業務組合」。就像寄存水果盤子，不應要求保管處切水果擺盤。
- 資料表滲透業務層：到處可見欄位名而非領域物件，違反《企業應用架構模式》原則。
適度使用儲存程序可，但不可作為核心業務邏輯載體。
Hibernate/ORM 使用誤區：不是工具慢，是建模錯
- 為了配合既有資料表結構，將 `lazy=false` 強制載入關聯 → 效能災難。
- ORM 目標是**領域模型持久化**，若先設計資料表再硬套映射，業務物件必然扭曲為 DTO，導致效能與維護雙失。
- 領域驅動設計（DDD）才是解決 ORM 痛苦的正道：先建模，再映射；若不懂 DDD，寧可選「No ORM」。
Spring 分層矛盾：業務層缺乏 Session 支援
購物車等會話狀態被迫放入 `HttpSession`（表現層），導致業務邏輯外洩、分層混亂。這違背引入 Spring 的初衷。
DDD：重新校準架構選型羅盤針
- DDD 非新理論，而是實戰經驗總結。
- 核心：分層架構（表現、服務、領域、基礎設施）與領域建模。
- 框架選型標準：能否協助實現分層與領域模型？不能則捨棄。
- 避免陷入技術細節迷霧，迷失架構本質方向。
結語
Java 專案成敗關鍵在於：擁抱 OO 思維、堅守分層原則、以領域模型為核心、審慎選用技術。唯有如此，軟體才能擁有生命力，隨業務演進而優雅成長。
