歷史回顧：從輝煌到質疑
2000 年前 EJB 被視為企業級開發銀彈，承諾簡化開發、降低成本、跨平台部署。實際落地卻暴露：開發複雜度劇增、效能調優困難、部署成本高昂、廠商鎖定嚴重。Spring 等輕量級框架崛起，EJB 陷入信任危機。
核心矛盾：組件復用 vs 實際應用
- 過度設計：簡單 CRUD 系統強行套用 EJB，引入不必要的遠程介面、Home 介面、部署描述檔。
- 顆粒度錯置：將細粒度領域物件做成 Entity Bean，導致大量網路往返（著名的 N+1 問題）。
- 狀態管理誤區：Stateful Session Bean 濫用造成叢集複寫風暴、序列化開銷大。
六大關鍵反思問題
- 軟體工程是否已超越組件時代？微服務、Function-as-a-Service 是否取代了傳統組件裝配？
- 復用是否僅需 API 調用而非二進制組件裝配？
- 商業邏輯封裝與強健性是否仍屬剛需？
- 組件的強健性、可用性能否由服務網格、Sidecar 等基礎設施層承擔？
- 是否有更廉價、生態更豐富的組件形式（Spring Bean、CDI Bean、Microservice）？
- .NET 元件模型與 EJB 是否具可比性？
理性定位：EJB 的生存空間
- ✅ 複雜分散式交易、高併發狀態業務、嚴格 ACID 需求的核心金融/電信系統
- ✅ 需標準化遠程介面、安全傳播、叢集透明遷移的異構整合場景
- ❌ 簡單 Web 應用、REST API、微服務邊界內的業務邏輯
結論
技術不應被神話，亦不應被輕易否定。EJB 在擅長領域（分散式事務、強一致性狀態服務）仍無直接替代者。關鍵在於技術選型必須匹配業務複雜度，避免「殺雞用牛刀」或「用手術刀劈柴」。
