EJB 對面向物件設計的侵蝕與重構之路：從臃腫 Bean 到領域模型

專案背景

嚴重依賴 EJB 的 CS 架構產品：胖客戶端 → EJB 業務介面 → DAO。業務邏輯複雜，UI 層非簡單 CRUD。

初期錯誤：EJB 當成「程序庫」

• 客戶端需什麼功能，EJB 就暴露什麼方法。
• CustomerBean 塞進「購買、退貨、換貨」所有邏輯；ProductBean 塞進「定義、價格」邏輯。
• EJB 變成面向過程的交易腳本，而非物件。

後期後果：單體 Bean 怪物

• 方法數爆炸，相似邏輯複製貼上（buyProductV1, buyProductV2...）。
• 硬編碼流程，零重用，測試困難（需啟動容器）。
• 文檔雖全但代碼「難看」，維護成本指數級上升。

重構藍圖：EJB 做薄，領域模型做厚

1. 業務細分與領域物件建模

識別核心領域概念：Customer、Product、Order、PricingStrategy... 每個負責單一業務職責。

2. EJB 退化為「轉發器/協調者」

@Stateless
public class OrderServiceBean implements OrderService {
    @EJB private InventoryService inventory;
    @EJB private PricingService pricing;

    public OrderDTO placeOrder(OrderRequest req) {
        // 1. 解析/驗證請求
        // 2. 協調領域物件
        Customer customer = customerRepo.find(req.getCustomerId());
        Order order = customer.placeOrder(req.getItems(), pricing, inventory);
        // 3. 持久化
        orderRepo.save(order);
        // 4. 組裝回傳 DTO
        return toDTO(order);
    }
}

• EJB 負責：事務邊界、安全性、遠端介面、流程編排。
• 領域物件負責：業務規則、狀態變更、不變條件。

3. 領域物件範例

public class Customer {
    private List orders = new ArrayList<>();
    public Order placeOrder(List items, PricingService pricing, InventoryService inventory) {
        Order order = new Order(this, items);
        order.price(pricing);
        order.reserveStock(inventory);
        orders.add(order);
        return order;
    }
}

收益

• 高內聚低耦合：業務邏輯集中在領域物件，易測試（純單元測試、無容器）。
• 重用性：PricingStrategy 可被多個流程複用。
• 演進性：新增業務規則只擴充領域模型，EJB 介面穩定。

避坑指南

1. 專案啟動前先做領域建模，再定義 EJB 介面粒度。
2. EJB 方法參數/回傳用 DTO，隔離領域模型與遠端契約。
3. 引入 Repository 模式 封裝 DAO，領域層依賴介面而非實作。
4. 定期重構：識別「交易腳本」味道（巨大方法、基本型別痴迷、邏輯分散），提煉領域物件。

EJB 是技術基礎設施，不是業務架構。讓 EJB 做它擅長的事（事務、安全、分佈），把業務還給物件。