從 DOS 時代的 FoxBase 財務系統、Windows 時期的 VB/PB 重寫、B/S 架構再重寫、到 RIA 浪潮又一次重寫——中國軟體產業長期陷入「技術更迭即全盤重寫」的惡性循環。這不僅是資源浪費，更導致領域知識流失、業務與技術脫節、人才成長斷層。
核心癥結：應用系統規範性太低、耦合度太高。作業系統能支撐萬種軟體演進，為什麼我們的應用適應不了單一企業的變化？
| 階段 | 代表技術 | 核心貢獻 | 局限 |
|---|---|---|---|
| 早期探索 | COM / CORBA | 確立二進制元件介面、跨語言互操作 | 平台鎖定、複雜度高、部署困難 |
| 企業級標準化 | EJB 1.x/2.x | 強制分層、聲明式交易/安全、容器管理生命週期 | 過度設計、入門門檻高、測試困難 |
| 輕量級反叛 | Spring Framework | IOC/DI 解耦、AOP 切面、POJO 程式模型、簡化測試 | 早期 XML 地獄、無標準規範 |
| 標準回歸 | EJB 3 / JPA / CDI | 註解驅動、極簡 API、整合 JPA、標準化 CDI | 容器啟動慢、生態相對封閉 |
Rod Johnson 基於多年 EJB 實戰經驗創造 Spring，並非否定 EJB，而是提煉其精華 (IOC、AOP、聲明式交易) 去除其糟粕 (重型容器、實體 Bean、遠端介面強制)。盲目崇拜 Spring 簡化而忽視組件化解耦本質，是許多團隊淪為「配置工程師」的根源。
汽車工業：橡膠、鋼鐵、引擎、車身、電子系統——專業分工、標準化介面、大規模協作。軟體業同理：
| 角色 | 錯誤行為 | 正確踐行 |
|---|---|---|
| 程式設計師 | 複製貼上、忽視設計、追逐新框架 | 精進設計模式、重構債務、建立元件庫 |
| 開發商/ISV | 專案制交付、無產品化、客製化泛濫 | 提煉產品線、標準化交付件、開放 API 生態 |
| 系統整合商/SI | 全棧自研、技術棧鎖定客戶 | 組裝最佳元件、負責整合品質、交付可維運系統 |
| CTO/CIO/企業主 | 只看交付速度、忽視技術債 | 拒收無測試/無文檔/高耦合系統、投資平台建設 |
# 核心原則：Spring 已基本解決「解耦」難題
# 1. 業務邏輯 → Spring @Service + @Transactional (POJO)
# 2. 資料存取 → Spring Data JPA / MyBatis (Repository 介面)
# 3. 遠端服務 → Spring Cloud / gRPC / REST (契約優先)
# 4. 非同步處理 → @Async / Spring Cloud Stream / Kafka
# 5. 監控追蹤 → Micrometer + Prometheus + Grafana / SkyWalking
# EJB 3 適用場景：
# - 已投資 Java EE 容器 (WebLogic/WildFly/GlassFish)
# - 需要標準化 CMP/遠端 EJB/Timer Service
# - 團隊熟悉 Java EE 規範而非 Spring 生態組件化不是銀彈，但它是通往軟體工業化的必經之路。EJB 與 Spring 同源共祖，都指向同一個理想：讓軟體像硬體一樣可組裝、可替換、可演進。這需要技術人員的堅守、管理者的投入、產業的協作。從今天開始，為你的每一行代碼負責——它未來一定會成為別人的元件。
