董云舟1. 我为什么在经历过建表驱动的开发后，转向了DDD
先说说我自己的背景。我大概有十年左右的Java后端经验，早期做传统企业应用，后来做互联网业务系统。很长一段时间里，我写代码的方式是“建表驱动”——拿到需求先设计数据库表，表定好了，代码照着CRUD写，Service层堆满业务逻辑，一个方法几百行是常事。系统前两年还好，第三年开始变味：加一个字段要关联十几个表，改一个逻辑要排查六七个Service，新人上手先折腾两周环境，再看两周代码才能接需求。每次迭代，光“理解现有逻辑为什么这样写”就要耗掉大半时间。
后来我接触到领域驱动设计（DDD），最初的想法很简单：把业务逻辑从数据模型里解出来。但真正研究进去之后，我才发现DDD解决的远不止是代码组织问题，它本质上是一套用统一语言把业务复杂度转化为软件结构复杂度的方法论。核心价值不是让你画出漂亮的架构图，而是让你的代码和业务模型保持同构——业务怎么运转，代码就怎么组织。这是我在实践中最深刻的体会。
这篇文章我不打算给你看标准概念定义，重点是说清楚我自己踩过的坑、总结出的方法，以及从需求到代码的完整映射过程。适合谁看？如果你正被“Service层越来越臃肿”“领域模型沦陷成数据载体”“微服务边界怎么划”这些问题困扰，这篇文章的内容基本都能覆盖到。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实体、值对象、聚合：这三个概念决定你的业务模型是否干净
DDD 的战术设计里，实体（Entity）、值对象（Value Object）、聚合（Aggregate）是绕不开的底子。很多团队也看了几本书，但一落地就懵：到底什么该建模成实体，什么该建模成值对象？聚合边界画到哪里合适？这些问题不解决，后面所有设计都是空中楼阁。
2.1 实体与值对象的划分，看的是“身份”和“生命周期”
实体最重要特征是持续的身份标识。一个用户，无论他的姓名、手机号怎么改，这个用户始终是同一个用户。我们要始终能够定位到他的记录，并追踪他的状态变化。所以建模时，用户、订单、合同这类有明确身份、需要被单独追踪的对象，适合作为实体。
值对象相反，它描述的是某种属性或度量，本身没有独立身份。一个地址由省份、城市、街道、邮编组成，两个地址内容完全一样，你就说它们相等，而不需要区分“第一个地址”和“第二个地址”。钱加币种、时间段、坐标点，都是典型的值对象。
我见过很多团队，值对象用得很少。原因不难猜：持久化的时候，值对象通常要嵌入到某个表里，或者拆列存储，有些人觉得麻烦，干脆全部当成实体表，一个值对象一张表，还配一个主键ID。结果就是关联关系爆炸、查询复杂度直线上升。
注意：值对象虽然看似“只是数据”，但在领域模型里它承载了完整的业务约束。例如金额对象应当有币种和数值，而不是两个分开的字段，否则就给了业务“把美元当人民币加”的机会。
我的建议是：在建模初期把所有概念都列出来，先按“有没有身份”做一次粗筛，把明显是属性的东西归为值对象。等到做聚合划分时，值对象的归属自然就会清晰。
2.2 聚合边界怎么画，可以直接对应到业务不变量
聚合是DDD里最容易被误解的概念。网上流行一句话：“聚合是用来保证一致性的边界。”这句话对，但不够具体。我自己的理解是这样：聚合是一组必须同时满足业务不变量的对象集合，对外只能通过聚合根访问。你画聚合边界时，不是看“哪些对象经常一起查”，而是看“哪些对象必须保持一致性”。
举个例子，一个订单聚合，包含订单头、订单明细、收件地址、支付记录。一条订单明细的数量被修改之后，订单总额必须同步变化，这就是不变量。如果你允许客户端直接修改明细对象，它完全可能跳过订单总额的重新计算。这就要把明细放进聚合内部，明细的访问必须经过订单。
但是，聚合不是越大越好。很多人第一次设计聚合，恨不得把整个系统都放进一个聚合里，最大的好处是“一致性绝对没问题”——问题是并发效率太低。一个Order聚合如果小到只有订单头，大量操作不需要锁其他数据；如果大到把整个客户订单历史全部包进来，任何对订单的修改都要锁住一大片数据，系统很快就卡死。
我常用的画法分三步：
- 梳理业务场景中的业务不变式，比如“订单总金额=所有明细金额总和”“一个账户不能同时被两个销售认领”。
- 将需要同时满足这些不变式的对象聚到同一个聚合内，设一个聚合根作为唯一入口。
- 聚合之间只通过聚合根ID引用，不直接持有对方引用。
工程上，聚合和事务的边界经常被划等号。在传统单块架构里，“一个聚合 = 一次本地事务”比较常见。在分布式场景下，一个聚合内部当然还是要保证强一致，跨聚合的协作则可以交给领域事件做最终一致。这一点留在后面事件驱动部分再展开。
3. 限界上下文拆分：从“按技术分层”到“按业务能力划分”
如果说实体和值对象是DDD的战术动作，那限界上下文（Bounded Context）就是DDD的战略核心。我见过很多团队一上来就研究聚合、仓库、领域服务，但上下文画得一团糟，最后代码一样是一锅粥。限界上下文的核心任务，是把“业务能力的边界”作为系统划分的第一准则。
3.1 识别限界上下文的方法：动词先行
具体怎么识别？我建议从业务人员的语言入手。比如一个电商业务，业务方会说“下单”“支付”“发货”“售后”“退款”。这些动词背后，其实对应着一套独立的业务能力和规则。做上下文划分的时候，可以把这些动词分组，看看哪些动词必须共享同一套模型和数据，哪些只是互相通过事件协作。
一组通常就是候选的限界上下文。以我做过的一个订单系统为例，我们拆出了：
- 订单上下文：负责订单创建、明细更新、金额计算
- 支付上下文：负责发起支付、回调处理、对账
- 履约上下文：负责发货、物流跟踪、签收确认
- 售后上下文：负责退款、退货、换货
四个上下文之间，不共享数据库表，也不直接调用对方的Service接口，而是通过消息或 API 在上下文之间传递“已经发生的事实”。
这里很多人会问：拆这么细，一个简单的内部系统也这么做吗？我的观点是：限界上下文的粒度取决于组织规模和业务复杂度。团队就三五个人，业务也不复杂，硬拆成十个微服务是自找麻烦。但在一个代码库里，你仍然可以用模块化方式划分边界，分清楚领域模型归属。微服务不是DDD的必要条件，模块化才是。
3.2 共享内核与防腐层：防止糟糕的耦合悄悄溜进来
上下文之间免不了有共享的数据或功能。比如用户信息，几乎每个上下文都会用到。处理这个的标准做法是：
- 共享内核：把确实需要共享的少量模型放到一个共同的包里，但要严格限制范围，只有稳定、低变动的部分才放进去。我见过一个团队把用户表直接共享给五个上下文用，每次用户表加字段，五个服务全要回归测试，这就是共享内核没控制好。
- 防腐层：当你的上下文需要对接外部系统或者老系统时，防腐层是你的翻译官。它负责把外部模型转换成内部领域模型，让外部世界的变化不要传染到你的核心业务逻辑里来。
我自己在对接一个老旧的CRM系统时就深有体会。老CRM里的“客户”是一个大宽表，字段混杂着联系人、地址、跟进状态。如果直接把它的数据模型引入新的订单上下文，整个模型的“气味”就变差了。后来我们加了一个防腐层，对接服务输出的是我们自己的“客户”领域模型，里面只保留订单需要的字段和规则。后续老CRM升级字段结构，内部完全不受影响。
4. 领域事件驱动：从“调接口同步”到“发布-订阅解耦”
领域事件（Domain Event）我第一次接触时觉得也就是消息队列的应用，但真正用好之后，才意识到它是连接多个限界上下文最自然的方式，也是保持聚合边界不失控的重要工具。
4.1 领域事件命名与发布时机
领域事件的命名一定要用业务上发生过的事实，比如“订单已支付”“库存已扣减”“退款已发起”。不要命名为“OrderCreatedMessage”这种技术味很重的名字，统一语言的价值就在这里。
发布时机，我建议在领域服务或聚合根的方法执行完毕后发布，而不是在应用服务的事务提交前。为什么？因为聚合根方法执行完，表示业务规则已经完成校验和状态变更，此时发布事件表达的是“这个事实已经发生了”。如果你等数据库提交成功后再发，可能因为发布失败导致事件丢失；如果你在事务内发，又可能因为事务回滚导致事件和实际状态不一致。
工程上比较稳妥的做法是事务性发件箱：业务数据和事件记录在同一个本地事务里写入，然后由后台任务把事件发往消息队列。发布成功后标记事件为已发送。这样既不丢事件，也不存在回滚导致的事件错误。实现成本不高，可靠性提升很大，值得做。
4.2 事件风暴：把头脑里的模型按到墙上
提到领域事件，就不得不说说事件风暴（Event Storming）。这是我实践DDD时收获最大的协作方法，它不是建模工具，而是一种工作坊形式：把业务人员、产品经理、开发、测试聚在一起，用不同颜色的便签纸贴在墙上，蓝色写事件，橙色写命令，黄色写聚合，粉色写外部系统。
具体流程：
- 先让业务专家把“系统发生过什么”按时间线写出来，从触发到结束，完整走一遍业务生命周期。
- 开发团队针对每个事件反推“什么命令导致了这个事件”，对应的“聚合”是什么。
- 找出有“业务策略”的地方，比如审批、校验、价格计算，标注出来，这些位置通常需要领域服务。
- 把所有事件按业务阶段分组，每组就是一个候选的限界上下文。
我们做过一次全天的事件风暴，把原先模糊不清的“退货”流程彻底梳理了一遍。业务人员说“退货要审核”，开发问“什么条件下自动审核？什么条件要人工？”业务人员当场把规则写出来，团队马上贴在墙上。整面墙变成了一张业务全景图，后面建模型、划边界、写代码，全程都拿它当唯一参照。
提示：事件风暴最怕的是技术人员主导、业务人员旁观。一定要让业务专家多说话，开发的任务是提问和记录，不是替业务猜测规则。
5. 应用层、领域层、基础设施层：依赖倒置怎么落地
很多团队看过DDD的分层架构图，回到代码里还是不知道该把逻辑放到哪一层。我见过最普遍的现象是：应用服务（Application Service）里写满业务规则，事务脚本一个接一个，领域层被活活架空。这就是典型的贫血模型——所有对象只是数据载体，业务逻辑都堆在Service里。
5.1 三个层次的职责划分，用“谁来做决定”来判断
我判断一个方法该放哪，看的是这个逻辑是在做“业务决策”还是在做“流程协调”。
- 应用服务：只做协调。典型动作是“从仓库拿聚合、调用聚合方法、再存回去”，它不决定“这个订单能不能优惠”，它只是把“计算出优惠后金额”这个动作交给领域层。
- 领域服务：当某个业务规则不好归属到任何实体或值对象时，比如“两个账户之间转账”的规则涉及多个聚合，就放进领域服务里。
- 基础设施层：实现仓储接口、发送消息、调用外部API，向上层提供技术能力，不包含业务规则。
依赖方向永远是领域层向内，基础设施层向外实现接口。这样领域层不依赖任何框架和数据库，纯Java或纯业务语言就能表达完整业务逻辑，测试起来也特别舒服。我甚至可以直接在单元测试里new一个聚合，调用业务方法，不启动Spring容器。
5.2 仓库不等于DAO，先有聚合再谈持久化
仓库（Repository）是很多人容易搞混的概念。DAO是“数据访问对象”，关注的是表的CRUD；仓库是“聚合的存取接口”，关注的是把整个聚合作为一个整体取出和保存。也就是说，仓储接口的方法是以聚合为粒度的，比如OrderRepository::findById(orderId)返回整个订单聚合，save(order)保存整个聚合。
实现仓储时，我建议先用ORM或手写SQL把聚合内的表映射组装好，再对外提供仓储接口。聚合内有多个表，持久化时要保证在同一个事务里完成。保存时也优先保存整体，而不是只更新某个字段。这样虽然写起来多一些，但聚合的不变量不容易被打破。
我在实际项目里用过不少持久化方案，包括MyBatis、JPA，甚至还有用Event Sourcing的。JPA的关联映射和聚合结构天然兼容，但要注意懒加载和N+1问题；MyBatis的组装能力更强，适合复杂查询，但需要手写比较多映射。选型不纠结，关键是持久化细节不要泄漏到领域层。
6. 从零搭建一个订单模块：完整DDD实操过程
到这里理论讲了不少，我拿一个实际订单模块的搭建过程作为案例，把从需求到代码的流程串起来。
6.1 需求梳理和统一语言表
业务需求是这样：用户下单，订单包含多个商品明细，系统根据会员等级计算折扣，库存数量有限需要扣减，下单成功后系统异步通知仓储发货。
我们和业务人员过了一遍，整理出统一语言表：
| 业务术语 | 含义 | 对应模型 |
|---|---|---|
| 下单 | 用户提交订单的意图 | 命令 |
| 订单 | 一次购买行为的载体 | 聚合根 |
| 订单明细 | 订单中的单个商品行 | 聚合内部实体 |
| 会员折扣 | 根据等级计算折扣 | 领域服务 |
| 扣库存 | 商品库存减少 | 其他上下文的事件 |
6.2 聚合设计
订单聚合根设计为Order，包含明细集合OrderItem，不变量是“订单总金额=明细总金额之和”。会员折扣的计算涉及用户等级和商品信息，不归属具体聚合，放在OrderDiscountService领域服务里。
跨上下文交互上，订单创建成功后发布OrderPlaced领域事件，库存上下文订阅后执行扣库存操作。只要扣库存失败，通过补偿逻辑取消订单，最终达成一致。
6.3 关键Java代码结构
应用层代码：
java复制@Service
@Transactional
public class OrderApplicationService {
private final OrderRepository orderRepository;
private final OrderDiscountService discountService;
public OrderPlaceResult placeOrder(PlaceOrderCommand command) {
// 从仓储拿订单号生成器之类的依赖，建立订单聚合
Order order = Order.create(orderIdGenerator.nextId(), command.getCustomerId());
command.getItems().forEach(item -> order.addItem(item.getProductId(), item.getQuantity(), item.getUnitPrice()));
// 领域服务完成折扣计算
Money finalAmount = discountService.calculateDiscount(order, command.getMemberLevel());
order.applyDiscount(finalAmount);
// 校验业务规则
order.validate();
orderRepository.save(order);
// 发布领域事件
order.publishEvents();
return OrderPlaceResult.success(order.getId());
}
}
领域层代码：
java复制public class Order {
private OrderId id;
private CustomerId customerId;
private List<OrderItem> items;
private Money totalAmount;
private List<DomainEvent> domainEvents = new ArrayList<>();
private Order(OrderId id, CustomerId customerId) { ... }
public static Order create(OrderId id, CustomerId customerId) {
return new Order(id, customerId);
}
public void addItem(ProductId productId, Quantity quantity, Money unitPrice) {
OrderItem item = new OrderItem(productId, quantity, unitPrice);
items.add(item);
// 修改金额后重新计算总额，维持不变量
this.totalAmount = totalAmount.add(item.getSubTotal());
}
public void applyDiscount(Money discountAmount) {
this.totalAmount = totalAmount.subtract(discountAmount);
}
public void validate() {
if (items.isEmpty()) {
throw new BusinessException("订单至少需要一个明细");
}
if (totalAmount.isNegative()) {
throw new BusinessException("订单金额不能为负数");
}
}
public void publishEvents() {
if (totalAmount != null) {
domainEvents.add(new OrderPlaced(id, totalAmount));
}
}
}
仓储接口：
java复制public interface OrderRepository {
Order findById(OrderId orderId);
void save(Order order);
}
基础设施层用MyBatis实现该接口，在save里完成订单主表和明细表的事务写入。整个代码里，领域层完全不感知MyBatis的存在。
7. 实战中的坑与排查：DDD落地的4个深坑记录
理论再好，工程上还是会踩坑。我把这几年实践里最典型的几个问题记录下来，有些我自己就翻过车。
7.1 坑一：聚合太大，事务卡死
最早做订单聚合时，我把订单、支付记录、物流信息全塞进一个聚合里。结果每次修改订单，都要锁住整个聚合，高并发场景下下单接口频繁超时。
排查后发现问题出在聚合边界上。支付记录和物流信息虽然是订单的“附属信息”，但它们并不是每次订单修改都必须保证一致。把支付拆成支付上下文，物流拆成履约上下文，订单聚合只保留订单头和明细，并发问题一下就缓解了。聚合边界的本质是业务一致性范围，不是数据包含关系。
7.2 坑二：过度建模，小系统被DDD拖死
有一段时间我陷入“为DDD而DDD”的状态，一个用户登录功能都抽象出值对象、领域服务、事件。结果代码量翻倍，业务没变复杂，团队反而被绕晕了。
后来我给自己定了个原则：一个业务规则不超过两三个条件、不涉及跨聚合协作时，就不要强行套DDD。DDD的价值是处理复杂业务，不是给简单CRUD加戏。简单模块用传统三层照样没问题。
7.3 坑三：仓储接口泄漏了持久化特性
有个同事实现OrderRepository.findByStatusAndCreateTime方法，传参是SQL风格的枚举和日期范围。这个接口看起来不像仓储，像DAO。调用方被迫要知道存储层的数据结构，领域层和基础设施层边界就模糊了。
好的仓储接口应该用领域语言定义查询意图，比如findPendingOrders()、findReadyForShipment()，内部再去拼SQL。查询条件的语义在领域层表达，实现细节留给仓储。
7.4 坑四：领域事件和数据库事务不一致
生产环境出过一次事故：扣费成功后，通知仓储的消息没发出去，结果库存扣了、钱扣了，但仓库一直没发货。排查发现我们的“发布事件”是在事务提交之后调用消息API的，消息API超时导致事件丢失。
后来我们换成事务性发件箱模式，事件和业务数据一起入库，由定时任务扫表补偿发送，才彻底解决了这个问题。
8. 关于DDD，我现在的态度和一条实践忠告
做了这几个项目之后，我对DDD的态度从“万能银弹”变成了“业务复杂度的镜子”。凡是业务规则多、逻辑重、团队人数多，DDD能带来巨大收益；凡是业务流程简单、团队小，DDD反而可能成为负担。
所以如果你正在犹豫要不要上DDD，我的忠告是：先让业务人员把业务规则讲清楚，判断复杂度再选型。不要因为“DDD很流行”就硬上。真正让一个系统变好的，不是某个方法论的名字，而是边界清晰、模型一致、依赖方向正确的代码结构。DDD只是帮助你达成这些目标的一套工具。
最后分享一个小技巧：建模阶段多问一句“这个业务规则如果变化，会影响哪些模块？”如果影响面横跨好几个表或服务，说明这个规则可能已经跨越了限界上下文的边界，是时候考虑事件驱动或者拆分聚合了。这一问，常常比画一整天架构图管用。