架构演进之 DDD：从 CRUD 到领域驱动设计

前言每一个贫血模型背后都有一个渐行渐远的业务在软件开发的早期阶段我们通常从一个简单的 CRUD 应用开始。随着业务逻辑日益复杂代码库逐渐膨胀我们开始面临一个普遍的问题业务逻辑散落在各处核心概念模糊不清修改一处牵一发而动全身。这种困境的根源往往在于我们一直沿用着“面向数据库”的编程思维而非“面向业务”的建模思维。领域驱动设计Domain-Driven Design简称 DDD正是为解决这一问题而生。本文将带你回顾从 CRUD 到 DDD 的演进之路分析不同架构模式的优劣并探讨如何在实际项目中逐步引入 DDD。一、CRUD 的困境贫血模型的局限性1.1 典型的 CRUD 架构传统的 CRUD 应用通常采用分层架构Controller → Service → DAO → Database其中Controller接收请求参数校验返回响应Service业务逻辑事务管理DAO/Repository数据访问ORM 操作Entity数据表映射仅有 getter/setter这种架构下Entity 通常是一个“贫血模型”——只包含数据字段和简单的访问方法没有任何业务行为。1.2 一个典型的例子假设我们有一个订单系统业务规则包括订单只能由“待支付”状态转为“已支付”支付后需要扣减库存支付成功后发送通知在 CRUD 模式下代码通常是这样写的// 贫血的 Order 实体 Entity public class Order { Id private Long id; private Long userId; private BigDecimal amount; private String status; // PENDING, PAID, CANCELLED // ... getter/setter 省略 } // Service 层承载了所有业务逻辑 Service public class OrderService { Autowired private OrderRepository orderRepository; Autowired private InventoryService inventoryService; Autowired private NotificationService notificationService; Transactional public void payOrder(Long orderId) { Order order orderRepository.findById(orderId); // 业务规则校验 if (!PENDING.equals(order.getStatus())) { throw new BusinessException(订单状态不正确); } // 状态变更 order.setStatus(PAID); orderRepository.save(order); // 扣减库存 inventoryService.deductStock(order); // 发送通知 notificationService.sendPaymentSuccess(order); } }1.3 CRUD 模式的问题随着业务增长这种模式暴露出一系列问题问题表现业务逻辑泄露核心业务规则被分散在 Service 层不同 Service 可能重复实现相同逻辑领域概念缺失代码中只有“数据表”没有“业务概念”如“支付”只是一个状态字段的修改可维护性差业务规则变更时需要排查所有涉及该实体的 Service 方法测试困难业务逻辑与基础设施耦合单元测试需要大量 mock难以复用领域行为无法被其他服务复用只能复制粘贴二、DDD 的核心思想让领域模型成为核心领域驱动设计由 Eric Evans 在其著作中系统阐述核心思想是当业务复杂度上升时应该将注意力集中在领域本身让领域模型成为软件的核心。2.1 DDD 的战略设计战略设计关注的是宏观层面的划分限界上下文Bounded Context明确定义模型的边界不同上下文可以有同名但含义不同的概念上下文映射Context Mapping定义不同上下文之间的集成关系子域Subdomain将大系统划分为核心域、支撑域、通用域2.2 DDD 的战术设计战术设计提供了实现领域模型的具体工具概念说明实体Entity具有唯一标识和生命周期可变的业务对象值对象Value Object无唯一标识通过属性值定义不可变聚合Aggregate一组相关对象的集合通过聚合根统一访问领域服务Domain Service处理跨多个实体的业务逻辑领域事件Domain Event记录领域中发生的重要事情仓储Repository提供聚合的持久化抽象工厂Factory封装复杂对象的创建逻辑三、DDD 重构从贫血到充血让我们用 DDD 的思路重构上面的订单支付场景。3.1 第一步识别领域概念首先我们需要识别出核心的领域概念订单Order聚合根核心实体订单状态OrderStatus值对象金额Money值对象支付Payment领域事件订单支付服务可能涉及领域服务3.2 第二步构建充血模型// 订单聚合根 - 充血模型 public class Order { private OrderId id; // 值对象作为ID private UserId userId; // 值对象 private Money totalAmount; // 值对象 private OrderStatus status; // 值对象 private ListOrderItem items; // 实体集合 // 聚合根负责保证内部一致性 public void pay() { // 状态校验 - 业务规则内聚在实体中 if (!this.status.canPay()) { throw new DomainException(订单当前状态无法支付); } // 状态变更 this.status OrderStatus.PAID; // 注册领域事件 registerEvent(new OrderPaidEvent(this.id, this.userId, this.totalAmount)); } public void addItem(Product product, int quantity) { // 添加订单项可能涉及业务规则 if (this.status.isPaid()) { throw new DomainException(已支付订单不能添加商品); } OrderItem item new OrderItem(product, quantity); this.items.add(item); this.totalAmount calculateTotalAmount(); } private Money calculateTotalAmount() { return this.items.stream() .map(OrderItem::getSubtotal) .reduce(Money.ZERO, Money::add); } } // 值对象 - 订单状态 public class OrderStatus { private final String value; public static final OrderStatus PENDING new OrderStatus(PENDING); public static final OrderStatus PAID new OrderStatus(PAID); public static final OrderStatus CANCELLED new OrderStatus(CANCELLED); private OrderStatus(String value) { this.value value; } public boolean canPay() { return this PENDING; } public boolean isPaid() { return this PAID; } // 重写 equals/hashCode } // 值对象 - 金额 public class Money { private final BigDecimal amount; private final Currency currency; public Money add(Money other) { if (!this.currency.equals(other.currency)) { throw new IllegalArgumentException(货币单位不一致); } return new Money(this.amount.add(other.amount), this.currency); } // ... 其他方法 }3.3 第三步领域服务与仓储// 仓储接口 - 定义在领域层 public interface OrderRepository { Order findById(OrderId id); void save(Order order); } // 领域服务 - 处理跨聚合的业务逻辑 Service DomainService public class PaymentDomainService { private final OrderRepository orderRepository; private final InventoryService inventoryService; // 防腐层接口 private final DomainEventPublisher eventPublisher; public void handleOrderPaid(OrderPaidEvent event) { // 支付后的跨聚合操作 inventoryService.deductStock(event.getOrderId()); eventPublisher.publish(event); } } // 应用层 - 编排领域对象 Service public class OrderApplicationService { private final OrderRepository orderRepository; private final PaymentDomainService paymentService; Transactional public void payOrder(PayOrderCommand command) { Order order orderRepository.findById(command.getOrderId()); // 业务逻辑在领域对象内部 order.pay(); orderRepository.save(order); // 处理领域事件 order.getEvents().forEach(paymentService::handleOrderPaid); } }四、架构对比两种思维模式维度CRUD 模式DDD 模式核心关注点数据如何存储业务如何运转模型特征贫血模型只有数据充血模型数据行为业务逻辑位置Service 层实体/值对象/领域服务封装性差业务规则暴露在外好通过聚合根保证一致性代码表达力技术实现导向业务概念导向适合场景简单 CRUD、管理后台复杂业务逻辑、核心业务系统五、演进策略如何逐步引入 DDD对于已有系统全面重构为 DDD 往往风险较高。推荐采用渐进式演进策略5.1 第一步识别核心域从业务价值最高的模块开始。核心域是公司核心竞争力所在最值得投入。5.2 第二步定义限界上下文明确新模块的边界避免与现有系统过度耦合。可以建立防腐层Anti-Corruption Layer隔离旧系统。5.3 第三步构建领域模型与领域专家深度合作用事件风暴Event Storming等方法探索领域知识建立统一的领域语言Ubiquitous Language。5.4 第四步逐步替换新功能直接用 DDD 实现旧功能在修改时逐步重构建立领域层与应用层分离的清晰边界5.5 演进过程中的注意事项不要为了 DDD 而 DDD简单系统用 CRUD 完全够用保持务实不是所有概念都需要值对象不是所有实体都需要工厂重视团队能力DDD 对团队的业务理解能力和设计能力要求较高基础设施不影响领域仓储接口定义在领域层实现放在基础设施层六、DDD 的适用场景DDD 并非银弹它有自己的适用边界适合采用 DDD 的场景业务逻辑复杂规则多变需要长期维护和演进的核心系统团队具备领域建模能力有领域专家可以深度协作不适合采用 DDD 的场景简单的 CRUD 应用技术原型或短期项目团队缺乏领域建模经验业务逻辑简单以数据展示为主七、结语回到业务本身从 CRUD 到 DDD本质上是一种思维方式的转变从“如何存储数据”转向“如何表达业务”。DDD 的实践确实会带来一定的复杂度但当业务足够复杂时这种复杂度是值得的。它帮助我们建立团队与业务方的共同语言让代码成为业务的忠实表达在业务变化时保持系统的可演进性正如 Eric Evans 所说“领域建模不是一项技术活动而是一项知识探索活动。”当我们真正理解业务并让代码反映这种理解时我们就走出了 CRUD 的困境进入了领域驱动的世界。演进之路没有终点只有持续的探索与优化。愿我们在每一次重构中离业务本质更近一步。