一 泛化基礎：理解DDD中的核心抽象機制

• 在領域驅動設計（Domain-Driven Design, DDD）中，泛化（Generalization）是一種強大的抽象工具，它允許我們識別和表達領域概念之間的"是一種"（is-a）關系。

1.1 什么是泛化？

• 泛化是指從多個特定概念中提取其共性，形成更一般化的概念的過程。在面向對象編程中，這通常通過繼承來實現，但在DDD中，泛化的含義更為廣泛。現實世界類比：想象你在設計一個動物園管理系統，特定概念：獅子、老虎、長頸鹿->泛化概念：動物。這里，"獅子是一種動物"就體現了泛化關系。

1.2 為什么泛化在DDD中重要？

1. 減少重復：共性行為可以放在父類中
2. 提高可維護性：修改一處即可影響所有子類
3. 增強表達力：更準確地反映業務領域的關系
4. 支持多態：允許以統一方式處理不同子類

1.3 泛化與特化的雙向關系

• 在這個類圖中，Animal是泛化類，Lion和Tiger是特化類。所有動物都有name和birthDate屬性，都能eat()和sleep()，但只有獅子能roar()，只有老虎能growl()。

二 DDD中泛化的實現形式

2.0 實現形式概覽

第一種是使用類的繼承。領域模型中的父類、子類，和實現中的父類、子類直接對應。它的特點在于必須有不同種類的特性或者不同的操作。如果僅僅是某個屬性值不同造成的泛化，那么用繼承就不合適了。
第二種是接口的實現。如果各個子類在屬性和操作實現方面沒有共性，但有相同的操作接口，就使用這種方式。
第三種是用特性的值來區分，這時候在實現層面，沒有父類和子類之分。特別適用于那些行為完全相同，僅在某些屬性值上存在差異的領域概念。

2.1 類繼承：最直接的泛化實現

• 電商系統示例：

public abstract class Payment {private BigDecimal amount;private Currency currency;private LocalDateTime paymentDate;public abstract void process();
}public class CreditCardPayment extends Payment {private String cardNumber;private String cardHolder;private LocalDate expiryDate;@Overridepublic void process() {// 信用卡支付處理邏輯}
}public class PayPalPayment extends Payment {private String email;private String transactionId;@Overridepublic void process() {// PayPal支付處理邏輯}
}

---

優劣分析：

• 優點：直接、明確、編譯器支持
• 缺點：Java等語言單繼承限制、父類修改影響大

2.2 接口實現：更靈活的泛化方式

public interface Shipment {void schedule();void cancel();TrackingInfo track();
}public class StandardShipment implements Shipment {// 實現標準物流
}public class ExpressShipment implements Shipment {// 實現快遞物流
}public class InternationalShipment implements Shipment {// 實現國際物流
}

---

適用場景：

• 當不同實現有完全不同的行為時
• 需要多重"泛化"時
• 強調能力而非共同結構時

2.3 組合優于繼承：現代DDD的實踐

public class Product {private String id;private String name;private PricingStrategy pricingStrategy;public BigDecimal calculatePrice(OrderContext context) {return pricingStrategy.calculate(this, context);}
}public interface PricingStrategy {BigDecimal calculate(Product product, OrderContext context);
}public class StandardPricing implements PricingStrategy {// 標準定價策略
}public class DiscountPricing implements PricingStrategy {// 折扣定價策略
}public class BundlePricing implements PricingStrategy {// 捆綁定價策略
}

優勢：

• 運行時可替換策略
• 避免類爆炸
• 更符合"組合優于繼承"原則

2.4 特征值實現：馬匹管理

• 其中：所有馬都有相同的屬性和行為、唯一區別是顏色不同（棗紅馬、白馬、黑馬等）。

public class Horse {private String name;private int age;private HorseColor color;  // 類型區分字段public Horse(String name, int age, HorseColor color) {this.name = name;this.age = age;this.color = color;}public void run() { /* 奔跑實現 */ }public void eat() { /* 進食實現 */ }// 特定于顏色的行為（如果需要）public String getDescription() {return color.getDescription() + "馬";}
}public enum HorseColor {RED("棗紅"),WHITE("白"),BLACK("黑"),PALOMINO("金鬃"),DAPPLE("花斑");private final String description;HorseColor(String description) {this.description = description;}public String getDescription() {return description;}
}

public class HorseService {public void demo() {Horse redHorse = new Horse("赤兔", 5, HorseColor.RED);Horse whiteHorse = new Horse("的盧", 4, HorseColor.WHITE);System.out.println(redHorse.getDescription());   // 輸出: 棗紅馬System.out.println(whiteHorse.getDescription()); // 輸出: 白馬// 所有馬統一處理List<Horse> horses = List.of(redHorse, whiteHorse);horses.forEach(Horse::run);}
}

三 DDD中泛化的高級應用

3.1 限界上下文中的泛化

• 在不同限界上下文中，同一概念的泛化可能不同。醫院系統示例：

患者管理上下文：

預約系統上下文：

• 注意在不同上下文中，泛化層次和標準完全不同。

3.2 泛化的層次設計

銀行賬戶系統示例：

設計考量：

1. 抽象層次不宜過深（通常不超過3層）
2. 每個層次都應增加明確的業務價值
3. 避免過度設計，只為真正的業務差異創建子類

3.3 泛化與持久化的權衡

• JPA繼承策略示例：

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "account_type")
public abstract class BankAccount {@Idprivate String accountNumber;private BigDecimal balance;// 公共字段
}@Entity
@DiscriminatorValue("SAVINGS")
public class SavingsAccount extends BankAccount {private BigDecimal interestRate;// 特有字段
}@Entity
@DiscriminatorValue("CHECKING")
public class CheckingAccount extends BankAccount {private BigDecimal overdraftLimit;// 特有字段
}

三種繼承映射策略對比：

策略類型	數據庫結構	優點	缺點
SINGLE_TABLE	單表，用區分字段標識子類	查詢高效，無需連接	字段稀疏，可能有NULL
JOINED	父類子類分開表，主鍵關聯	結構規范，無冗余	查詢需連接，性能較差
TABLE_PER_CLASS	每個具體類對應完整表	查詢具體類高效	多態查詢需UNION，設計復雜

四 避免泛化的常見陷阱

4.1 過度泛化：當抽象變成負擔

反例：

public abstract class Entity {private Long id;// 所有實體都需要的字段
}public abstract class Person extends Entity {private String name;private String email;// 所有人共有的字段
}public abstract class User extends Person {private String username;private String password;// 所有用戶共有的字段
}public class Customer extends User {// 客戶特有字段
}public class Employee extends User {// 員工特有字段
}public class SystemAdmin extends Employee {// 系統管理員特有字段
}

問題分析：

• 層次過深，修改基類影響范圍大
• 中間抽象類可能包含不相關功能
• 實際業務需求可能不需要如此復雜的層次

4.2 錯誤泛化：混淆本質差異

錯誤案例：

public abstract class PaymentMethod {private BigDecimal amount;public abstract void process();
}public class CreditCard extends PaymentMethod {// 信用卡支付
}public class Invoice extends PaymentMethod {// 發票支付
}public class BankTransfer extends PaymentMethod {// 銀行轉賬
}public class Coupon extends PaymentMethod {// 優惠券
}

問題：

• 優惠券本質上不是支付方式，而是折扣機制
• 強行泛化導致業務邏輯混亂
• 更好的設計是將Coupon作為獨立的折扣概念

4.3 泛化導致的數據污染

• 問題示例：

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public abstract class Notification {@Idprivate Long id;private String recipient;private String content;private LocalDateTime sentTime;// 其他公共字段
}@Entity
public class EmailNotification extends Notification {private String emailSubject;private String ccList;
}@Entity
public class SMSNotification extends Notification {private String phoneNumber;
}@Entity
public class PushNotification extends Notification {private String deviceToken;private String appId;
}

問題：

• 單表策略下，表會包含所有子類的字段
• 大多數記錄會有大量NULL字段
• 隨著子類增加，表會變得臃腫

解決方案：

• 考慮使用JOINED策略
• 或將完全不相關的通知類型拆分到不同限界上下文

五、實戰案例：電商系統中的泛化設計

5.1 商品類別的泛化設計

• 初始設計：

演進設計（考慮更多業務需求后）：

設計演進說明：

1. 從簡單的繼承層次轉變為更靈活的混合模式
2. 使用接口（或mixin）表示橫切關注點
3. 將定價策略分離出來，符合單一職責原則
4. 每個產品可以組合不同的特性

5.2 訂單處理的狀態模式實現

public class Order {private String orderId;private OrderState state;public void cancel() {state.cancel(this);}public void approve() {state.approve(this);}public void ship() {state.ship(this);}public void deliver() {state.deliver(this);}// 狀態轉移方法void changeState(OrderState newState) {this.state = newState;}
}public interface OrderState {void cancel(Order order);void approve(Order order);void ship(Order order);void deliver(Order order);
}public class DraftState implements OrderState {// 實現草案狀態的行為
}public class ApprovedState implements OrderState {// 實現已批準狀態的行為
}public class ShippedState implements OrderState {// 實現已發貨狀態的行為
}public class DeliveredState implements OrderState {// 實現已交付狀態的行為
}public class CancelledState implements OrderState {// 實現已取消狀態的行為
}

優勢：

1. 每個狀態的行為集中在一處
2. 避免大量的if-else條件判斷
3. 新狀態易于添加
4. 狀態轉換邏輯明確

六 總結與最佳實踐

6.1 何時使用泛化？

適合使用泛化的情況：

• 存在明確的"是一種"業務關系
• 多個概念有顯著共享的行為和屬性
• 需要以統一接口處理不同概念時
• 業務領域本身有明顯的分類體系

---

應避免泛化的情況：

• 僅為了代碼復用而強行抽象
• 差異大于共性的情況
• 未來可能有根本性差異的概念
• 技術驅動而非業務驅動的分類

6.3 泛化的替代方案

當泛化不合適時，考慮：

1. 組合：將共性部分提取為獨立組件
2. 策略模式：將變化的行為抽象為策略
3. 裝飾器模式：動態添加功能
4. 角色模式：允許對象動態獲得能力

6.4 持續重構的視角

泛化設計應是演進式的：

1. 開始時可以扁平化設計
2. 隨著重復代碼的出現識別共性
3. 當業務規則差異明確時引入抽象
4. 定期審視泛化層次是否仍然合理

• 記住Eric Evans的話：“深層次模型是逐步演進而非一次性設計出來的，它需要開發人員和領域專家持續協作，通過多次迭代精煉而成。”