架构演进之 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 List<OrderItem> 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 的困境，进入了领域驱动的世界。
演进之路没有终点，只有持续的探索与优化。愿我们在每一次重构中，离业务本质更近一步。