DDD实战指南：从CRUD走向业务架构师，以电商订单系统为例

当我们面对复杂业务系统时，传统开发模式会暴露出三个致命问题：

问题1：业务逻辑分散

在贫血模型中，一个完整的业务操作被拆分到多个Service中。比如订单取消：

• OrderService修改状态
• PaymentService处理退款
• InventoryService恢复库存
• NotificationService发送通知

业务规则散落各处，修改时容易遗漏。

问题2：代码与业务脱节

数据库表结构驱动设计，导致：

• 类名是OrderDO，而不是Order
• 方法名是updateStatus()，而不是cancel()
• 字段设计考虑的是查询性能，而不是业务含义

问题3：沟通成本高昂

业务人员说的“库存”和开发实现的“库存”不是一回事，导致需求理解偏差。

二、DDD三大核心理念

理念1：领域模型驱动设计

代码结构应该反映业务结构，而不是数据库结构。

传统方式：

// 贫血模型：只有数据没有行为
public class OrderDO {
    private Long id;
    private BigDecimal amount;
    private String status;
    // 只有getter/setter
}

// 业务逻辑在Service中
public class OrderService {
    public void cancelOrder(Long orderId) {
        OrderDO order = orderDao.selectById(orderId);
        order.setStatus("CANCELLED");
        orderDao.updateById(order);
        // 还要处理退款、库存、通知...
    }
}

DDD方式：

// 充血模型：数据+行为
public class Order {
    private OrderId id;
    private Money amount;
    private OrderStatus status;

    // 业务方法：取消订单
    public void cancel(String reason) {
        // 业务规则校验
        validateCancellable();
        // 状态变更
        this.status = OrderStatus.CANCELLED;
        this.cancelReason = reason;
        // 发布领域事件
        addDomainEvent(new OrderCancelledEvent(this.id, reason));
    }

    private void validateCancellable() {
        if (this.status != OrderStatus.CREATED
            && this.status != OrderStatus.PAID) {
            throw new IllegalStateException("订单当前状态不可取消");
        }
        if (isShipped()) {
            throw new IllegalStateException("已发货订单不可取消");
        }
    }
}

理念2：统一语言

建立团队共享的业务术语词典，确保业务、产品、开发使用同一套语言。

示例术语表：

业务术语	代码体现	错误用法
下单	Order.create()	addOrder()
支付	Payment.pay()	updatePaymentStatus()
发货	Order.ship()	sendGoods()

理念3：限界上下文

根据业务内聚性划分边界，每个上下文有自己独立的领域模型。

上下文划分原则：

1. 高内聚：同一上下文内业务紧密相关
2. 低耦合：不同上下文间依赖最小化
3. 独立演化：每个上下文可独立变化

三、实战案例：电商订单系统重构

现状分析

原有订单系统采用传统三层架构，存在以下问题：

// 原有代码结构
@Service
public class OrderService {
    // 2000行代码，包含所有订单相关逻辑
    public void createOrder() { /* 100行 */ }
    public void cancelOrder() { /* 150行 */ }
    public void payOrder() { /* 120行 */ }
    public void refundOrder() { /* 180行 */ }
    // ... 还有其他20多个方法
}

@Entity
public class Order {
    // 只是数据对象，没有业务逻辑
    @Id private Long id;
    private BigDecimal amount;
    private String status;
    // 20多个字段，包含各种业务信息
}

痛点：

1. OrderService成为上帝类，难以维护
2. 业务规则隐藏在Service的if-else中
3. 新人需要阅读所有代码才能理解业务

DDD重构方案

步骤1：识别核心领域

通过业务分析，识别出订单系统的核心领域：

• 订单核心域：订单生命周期管理
• 支付支撑域：支付处理
• 库存通用域：库存管理

步骤2：设计聚合

将订单设计为聚合根，包含订单项作为内部实体：

// 订单聚合根
public class Order {
    private OrderId id;
    private UserId userId;
    private List<OrderItem> items;
    private OrderStatus status;
    private Money totalAmount;
    private Address shippingAddress;

    // 工厂方法：创建订单
    public static Order create(UserId userId, List<OrderItem> items,
                               Address address, Discount discount) {
        Order order = new Order();
        order.id = OrderId.generate();
        order.userId = userId;
        order.items = new ArrayList<>(items);
        order.status = OrderStatus.CREATED;
        order.shippingAddress = address;

        // 计算金额
        order.totalAmount = order.calculateTotalAmount();
        // 应用优惠
        if (discount != null) {
            order.applyDiscount(discount);
        }
        // 校验业务规则
        order.validate();
        // 发布领域事件
        order.addDomainEvent(new OrderCreatedEvent(order.id));
        return order;
    }

    // 业务方法：取消订单
    public void cancel(String reason) {
        // 校验是否可以取消
        if (!canBeCancelled()) {
            throw new OrderCannotCancelException("订单不可取消");
        }
        // 修改状态
        this.status = OrderStatus.CANCELLED;
        this.cancelReason = reason;
        // 发布事件
        addDomainEvent(new OrderCancelledEvent(this.id, reason));
    }

    // 业务规则：判断是否可以取消
    private boolean canBeCancelled() {
        return this.status == OrderStatus.CREATED
                || this.status == OrderStatus.PAID;
    }

    // 私有方法：计算总金额
    private Money calculateTotalAmount() {
        return items.stream()
                .map(OrderItem::getSubtotal)
                .reduce(Money.ZERO, Money::add);
    }
}

// 订单项（聚合内部实体）
public class OrderItem {
    private ProductId productId;
    private String productName;
    private Money price;
    private Integer quantity;

    // 计算小计
    public Money getSubtotal() {
        return price.multiply(quantity);
    }
}

步骤3：重构业务服务

将原有的庞大OrderService拆分为多个领域服务：

// 应用服务：协调领域对象完成用例
@Service
public class OrderApplicationService {
    private final OrderRepository orderRepository;
    private final InventoryService inventoryService;
    private final DomainEventPublisher eventPublisher;

    @Transactional
    public OrderResult createOrder(CreateOrderCommand command) {
        // 1. 验证库存
        inventoryService.reserve(command.getProductItems());
        // 2. 创建订单
        Order order = Order.create(
                command.getUserId(),
                command.getItems(),
                command.getAddress(),
                command.getDiscount()
        );
        // 3. 保存订单
        orderRepository.save(order);
        // 4. 发布事件
        eventPublisher.publishAll(order.getDomainEvents());
        return OrderResult.success(order.getId());
    }
}

// 领域服务：处理跨聚合业务逻辑
@Service
public class OrderCancellationService {
    public void cancelOrder(Order order, String reason) {
        // 1. 取消订单
        order.cancel(reason);
        // 2. 恢复库存（通过事件异步处理）
        // 3. 发起退款（通过事件异步处理）
        // 4. 发送通知（通过事件异步处理）
    }
}

步骤4：引入领域事件实现解耦

// 领域事件：订单已取消
public class OrderCancelledEvent implements DomainEvent {
    private OrderId orderId;
    private List<OrderItem> items;
    private String reason;
    private LocalDateTime occurredAt;
}

// 事件处理器
@Component
public class OrderCancelledEventHandler {
    @EventListener
    @Async
    public void handle(OrderCancelledEvent event) {
        // 恢复库存
        inventoryService.restore(event.getItems());
        // 发起退款
        paymentService.refund(event.getOrderId());
        // 发送通知
        notificationService.notifyUser(event.getOrderId(), "订单已取消");
    }
}

重构效果对比

指标	重构前	重构后	提升
OrderService行数	2000+行	300行	-85%
业务规则集中度	分散在多个Service	集中在Order聚合内	+300%
新人上手时间	2个月	2周	-75%
需求修改影响范围	需要修改多个Service	主要修改Order聚合	-70%
单元测试覆盖率	30%	85%	+183%

四、关键代码设计模式

1. 值对象设计模式

// 金额值对象
public class Money implements ValueObject {
    private final BigDecimal amount;
    private final Currency currency;

    private Money(BigDecimal amount, Currency currency) {
        this.amount = amount.setScale(2, RoundingMode.HALF_UP);
        this.currency = currency;
    }

    // 工厂方法
    public static Money of(BigDecimal amount, Currency currency) {
        return new Money(amount, currency);
    }

    // 业务方法：加法
    public Money add(Money other) {
        validateSameCurrency(other);
        return new Money(this.amount.add(other.amount), this.currency);
    }

    // 业务方法：乘法
    public Money multiply(int quantity) {
        return new Money(this.amount.multiply(BigDecimal.valueOf(quantity)), this.currency);
    }

    // 值对象比较
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Money money = (Money) o;
        return amount.compareTo(money.amount) == 0 && currency == money.currency;
    }
}

2. 仓储模式

// 仓储接口
public interface OrderRepository {
    Order findById(OrderId orderId);
    List<Order> findByUserId(UserId userId, Pageable pageable);
    void save(Order order);
    void delete(Order order);
    // 特定业务查询
    List<Order> findCancellableOrders();
}

// 仓储实现
@Repository
public class OrderRepositoryImpl implements OrderRepository {
    private final OrderJpaRepository jpaRepository;
    private final OrderMapper mapper;

    @Override
    public Order findById(OrderId orderId) {
        OrderDO orderDO = jpaRepository.findById(orderId.getValue())
                .orElseThrow(() -> new OrderNotFoundException(orderId));
        // 转换为领域对象
        return mapper.toDomain(orderDO);
    }

    @Override
    public void save(Order order) {
        // 转换为持久化对象
        OrderDO orderDO = mapper.toDO(order);
        // 保存
        jpaRepository.save(orderDO);
        // 发布领域事件
        eventPublisher.publishAll(order.getDomainEvents());
        order.clearDomainEvents();
    }
}

五、DDD适用性评估框架

评估维度与权重

1. 业务复杂度（40%）
   • 1-3分：简单CRUD，规则固定
   • 4-7分：中等复杂度，有业务规则
   • 8-10分：高度复杂，规则频繁变化
2. 团队规模（20%）
   • 1-3分：1-3人
   • 4-7分：4-10人
   • 8-10分：10人以上
3. 系统生命周期（20%）
   • 1-3分：短期项目（<1年）
   • 4-7分：中期项目（1-3年）
   • 8-10分：长期系统（>3年）
4. 领域知识门槛（20%）
   • 1-3分：业务简单易懂
   • 4-7分：需要领域知识
   • 8-10分：专业领域知识

计算公式 总分 = 业务复杂度×0.4 + 团队规模×0.2 + 系统生命周期×0.2 + 领域知识门槛×0.2

决策矩阵

总分	建议	实施策略
<5分	不建议使用	传统分层架构即可
5-7分	部分采用	在核心域应用DDD
>7分	全面采用	全系统实施DDD

自测表 请回答以下问题（每题1-10分）：

1. 你的系统有多少个业务状态和状态转换？
2. 业务规则变更频率如何？
3. 新功能开发是否需要深入理解多个模块？
4. 系统是否存在数据不一致问题？
5. 团队沟通是否存在术语不一致？

六、落地实施路线图

阶段一：准备阶段（1-2周）

1. 团队培训：DDD基础概念培训
2. 业务梳理：识别核心业务流程
3. 试点选择：选择一个相对独立的核心域

阶段二：试点实施（2-4周）

1. 事件风暴：梳理试点域的领域事件
2. 领域建模：设计聚合、实体、值对象
3. 代码重构：实现领域模型
4. 测试验证：确保功能正确性

阶段三：推广扩展（4-8周）

1. 经验总结：总结试点经验
2. 模式固化：形成团队规范
3. 逐步推广：扩展到其他领域
4. 工具建设：开发代码生成、测试工具

阶段四：持续优化（持续）

1. 模型演进：根据业务变化调整模型
2. 性能优化：优化聚合设计和查询
3. 团队赋能：培养更多DDD实践者

七、常见陷阱与规避策略

陷阱1：聚合设计过大

• 问题：将过多实体放入一个聚合，导致并发冲突频繁、加载性能差、业务逻辑复杂。
• 解决方案：遵循“小聚合”原则，通过ID引用其他聚合，使用领域事件保持一致性。

陷阱2：领域服务滥用

• 问题：将所有业务逻辑都放入领域服务，回到贫血模型。
• 解决方案：优先将逻辑放在聚合内，领域服务只处理跨聚合逻辑，应用服务只负责协调。

陷阱3：忽略统一语言

• 问题：团队继续使用技术术语，DDD效果大打折扣。
• 解决方案：建立术语表并定期维护，代码中使用业务术语命名，需求评审时统一语言。

八、立即行动清单

今日可做（1小时内）

1. 识别系统中业务逻辑最分散的模块
2. 统计一个核心业务操作涉及的Service数量
3. 整理业务术语不一致的案例

本周可做（8小时内）

1. 选择一个核心实体尝试重构为聚合
2. 建立团队业务术语表
3. 组织一次小型事件风暴会议

本月可做（40小时内）

1. 完成一个核心域的DDD重构
2. 建立团队DDD编码规范
3. 分享重构经验给其他团队

九、技术栈选择建议

Java技术栈

• 框架：Spring Boot + Spring Data JPA
• 架构：六边形架构（端口适配器）
• 持久化：JPA/Hibernate（聚合）、MyBatis（查询）
• 事件：Spring Events或消息队列

C#技术栈

• 框架：.NET Core + Entity Framework Core
• 架构：整洁架构
• 持久化：EF Core（聚合）、Dapper（查询）
• 事件：MediatR或消息队列

工具支持

1. 建模工具：PlantUML（代码生成UML图）
2. 文档工具：Swagger（API文档）、Miro（事件风暴）
3. 测试工具：JUnit/Mockito（单元测试）、Cucumber（BDD）

十、效果评估指标

短期指标（1-3个月）

1. 代码质量：聚合内聚度、方法复杂度
2. 开发效率：需求实现时间、bug数量
3. 团队认知：业务理解一致性

长期指标（6-12个月）

1. 系统稳定性：生产问题减少率
2. 维护成本：缺陷修复时间
3. 业务响应：新需求上线速度

量化目标

• 核心域代码行数减少30%以上
• 业务规则集中度提升50%以上
• 新人上手时间缩短60%以上
• 生产问题减少40%以上

十一、总结

DDD不是一套可以简单套用的框架，而是一种需要持续实践的设计思维方式。它的核心价值在于：

1. 对齐业务与代码：让软件真正反映业务需求
2. 管理复杂度：通过边界划分控制复杂度增长
3. 提升沟通效率：统一语言减少理解偏差
4. 支持持续演进：适应业务快速变化

关键成功因素：

• 高层支持与业务参与
• 团队共识与持续学习
• 渐进式实施与快速反馈
• 工具支持与规范建设

DDD的最终目标不是完美的领域模型，而是持续交付业务价值的能力。清晰的业务边界比完美的技术实现更重要。选择一个你负责的核心业务对象，尝试将其重构为DDD聚合，并记录重构过程和效果。