Day 27 - 订单系统DDD重构

📖 今日目标

1. 识别传统订单系统的问题
2. 设计DDD重构方案
3. 实现渐进式重构

重构背景

传统订单系统问题

1. 贫血模型：Order只是数据容器
2. 业务逻辑散落：Service层过于臃肿
3. 领域概念模糊：用户、商家、平台混杂
4. 难以测试：大量Mock依赖

重构方案

1. 识别聚合

传统设计：
┌─────────────────┐
│  OrderController │
├─────────────────┤
│  OrderService    │ ← 业务逻辑集中
├─────────────────┤
│  OrderDao        │
└─────────────────┘

DDD设计：
┌────────────┐     ┌────────────┐
│ Controller │────▶│ AppService │
├────────────┘     ├────────────┤
│                  │  Order     │ ← 业务逻辑内聚
│                  │  (Entity)  │
└──────────────────┴────────────┘

2. 实体改造

// 重构前：贫血模型
public class Order {
    private Long id;
    private List<OrderItem> items;
    
    public BigDecimal getTotal() {...} // 只有getter
}

// 重构后：充血模型
public class Order extends AggregateRoot {
    private OrderId id;
    private List<OrderItem> items;
    
    public void addItem(Product product, int qty) {...}
    public void place() {...}
    public void cancel() {...}
}

3. 渐进式重构策略

1. 先识别领域概念
2. 在现有Service中引入实体方法
3. 逐步迁移业务逻辑到实体
4. 最终移除Service中的业务代码

实践思考

🎯 思考题：

分析订单创建流程，列出需要迁移到Order实体的方法。

---

📅 学习进度

Day	主题	状态
01-26	电商领域建模实战	✅
27	订单系统DDD重构	✅
28	聚合边界设计实践	⬜
...	...	...
30	复习与总结	⬜

---

本文为DDD 30天学习计划第27天内容

📚 导航

| ← Day 26 - 上一章 | Day 28 - 下一章 →