镝不咸如果在五年前有人告诉我，我会认认真真写一篇关于 DDD（领域驱动设计）的实践复盘，我大概率觉得他看错了人。当年我接手一个中台项目，照着 Eric Evans 那本蓝皮书把实体、值对象、聚合、仓储、领域事件这些概念背得滚瓜烂熟，画了一堆自以为很漂亮的架构图。结果代码一写起来就露馅：领域模型全是贫血对象，业务逻辑最终还是堆在 Service 里，每次需求变更依旧要拉着业务专家问半天，然后小心翼翼地改一个我都不确定会不会影响别人的“核心类”。后来换了几个项目、带过几次开发小组，我才逐渐意识到，问题不在于 DDD 这套理论对不对，而在于我当时根本没理解它到底要解决什么。
这篇文章写给谁？如果你正在学 DDD，看过几本经典书或参加过培训，但到了真实项目里还是不知道从哪里开始切聚合、不知道限界上下文怎么划分、也不敢拍板说“这里应该用防腐层”，那这篇文章应该能给你一些参照。我会从认知误区、建模实操、战术设计、AI 协作、落地顺序五个方面，把这几年的真实感悟讲清楚，有踩坑记录，也有事后反推出来的正确做法。
1. 学完 DDD 依然写不出好代码，问题到底出在哪
1.1 当 DDD 变成了分层架构的新皮肤
我第一个 DDD 项目失败后，一度把原因归结为团队代码水平不行。后来带我的一位架构师看了代码，只问了一句：业务规则为什么全在 Service 里，模型里什么都没有？
我那时候很委屈，因为我觉得自己已经严格按照架构来写了。目录是标准的四层结构：
java复制com.example.order
├── application/OrderApplicationService.java
├── domain/Order.java
├── infrastructure/OrderRepositoryImpl.java
└── interfaces/OrderController.java
每个领域对象都建了 Entity 目录，Order 类有状态枚举、有 getId、getCreateTime，再加一堆 getter/setter。每个 Repository 都封装了数据库操作，Service 负责一切流程。从表面看，它完全符合很多文章讲的 DDD 架构，但骨子里还是传统的 Transaction Script——所有业务流程都写成脚本，每个方法负责一个用例，模型对象只是数据的搬运工。
那为什么我们当时还觉得这就是 DDD？因为代码评审只检查形式：是否分了 area/domain/infrastructure 层，是否用 Repository 封装了数据库，是否通过构造函数注入依赖。这种“形式合规”掩盖了实质缺失。
我现在理解，DDD 不是为了架构分层多一个 domain 包才出现的，它要解决的是业务复杂度带来的失控问题。如果一个系统的大部分需求都是增删改查，没有复杂的规则流转，没有多参与方之间的强制一致性要求，那传统分层不仅够用，而且更直接。DDD 的战术设计在简单 CRUD 场景下反而会显得笨重。
反过来说，当你发现 Service 里的方法越来越长，每加一个需求就要把某个“对象”的十几个字段状态都捋一遍，而且怎么捋都捋不清楚时，说明业务复杂度已经超过简单脚本能承载的上限。这时候才真正需要 DDD 站出来。
1.2 很多项目第一个卡点不是代码，是通用语言
再往深一层挖，我当时的失败不只是代码结构问题，团队连业务术语都没有对齐。很多团队把 DDD 的书翻到战略设计部分，看到“通用语言”就划过去了，觉得这是虚的。但它才是 DDD 整套体系里最难、也最值钱的部分。
举个真实案例。我在一个电商后台做救火队员时，发现产品经理、开发、客服、财务对“退款”这个词的理解完全不一样。产品说“退款”是用户提交申请的那一刻；财务说“退款”是钱真正打回用户账户的那一刻；客服说“退款”是后台手动把订单改成已退款状态。于是状态字段里同时出现了 refunding、refunded、finish_refund、refund_success 各种写法，有的流程判断的是申请时间，有的流程判断的是到账时间。每一次涉及退款的变更，都像在拆弹。
后来我们建了术语表，每个业务名词都写明：在哪个上下文出现、由谁创建、什么状态下使用、和哪些词是近义词但要区分。就是这个简单动作，让后续的需求评审效率提高了很多。因为大家终于发现，之前争论的很多东西根本不是同一个问题。
我经常说一句话：如果业务专家和开发坐在一起，对“订单已提交”这句话的理解都不一致，那后面无论用多高明的架构模式都是空中楼阁。DDD 解决的不是代码风格问题，而是认知对齐问题。
1.3 别把 DDD 当成要“完整落地”的框架
还有一个很常见的误区，是把 DDD 理解成一套必须全员整齐划一执行的开发流程。有人问“我们没有事件溯源，算不算 DDD？”有人问“值对象是不是必须不可变？”“没有 CQRS 是不是不完整？”我会反问一句：你引入这些模式是为了解决哪个具体痛点？
DDD 里面的模式是一张工具箱，不是合同。聚合解决一致性边界，值对象解决属性归属和比较逻辑，领域服务解决跨聚合的规则，事件解决上下文之间的最终一致。你用哪几个，取决于你的业务长什么样。很多订单系统用了事件驱动，而一个简单的审批流系统未必需要领域事件。完整落地不是目标，可维护、可演进才是。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从事件风暴到限界上下文：领域建模的真实打法
2.1 事件风暴的第一步不是约业务，而是收窄问题空间
谈起 DDD 落地，很多人第一个动作就是组织事件风暴工作坊。这个动作本身没错，但我见过太多失败案例：业务专家请了十几个，部门跨了三个，白板贴满了五颜六色的便签，最后产出的图大到根本没法用。
问题就在于第一步没有收窄。事件风暴的发起人应该先想清楚一个问题：我们这次要解决的业务问题是什么？比如当前系统最痛的点是库存超卖导致客诉，那我们要建模的重点就不是“订单全生命周期”，而是“库存的预占、扣减、释放”这一段闭环。
收窄问题空间之后，再决定请哪些人。如果只关注销售上下文和库存上下文的交互，就不必拉着财务团队参加完整场。不是财务不重要，而是他们关心的问题在这次建模里不应该是主角。范围越小，风暴会越高效，参与者越容易达成共识。
2.2 领域事件怎么命名、怎么排序，记录的全是真问题
事件风暴的核心产出是领域事件列表。很多人把这个环节做成“写便签”，但我会特别强调两个约束。
第一，命名必须用“业务上的客观事实”。比如“订单已提交”“库存已预占”“支付已完成”，而不是“提交订单”“预占库存”。这不是抠语法，而是一种思维训练：命令可能被拒绝，但事件代表已经发生的、不可否认的结果。当所有人习惯了用已经发生的事实来讨论业务，那些“我以为你会处理”“他以为我已经处理”的灰色地带就会暴露出来。
第二，事件排序要按业务时间流走，而不是按系统模块走。写下去之后你会发现，某两个事件之间有巨大空白，大家不知道中间发生了什么，或者某两个事件顺序在不同专家眼里是反的。这些地方往往就是系统最脆弱、需求最模糊的部分。
对着一串事件列表，业务专家很容易看出问题。比如下面这串事件：
text复制OrderSubmitted
OrderConfirmed
InventoryReserved
PaymentReceived
InventoryDeducted
OrderShipped
业务专家会很快指出：“支付成功之后不应该立刻扣减库存，应该是先通知仓库，仓库实际出库再扣减。”这句话一旦被记录下来，整个建模方向就会随之改变。真实的 DDD 实践不是把模型画出来再让业务签字，而是在这种争论中逐步逼近真相。
2.3 发现限界上下文的三个信号
限界上下文是 DDD 里最核心的战略设计概念，但它不是画出来的，是“发现”出来的。我从实战中总结出三个高频信号，只要出现其中一个，就值得怀疑当前建模边界是否合理。
第一个是语言分裂。同一个词，在两个角色嘴里含义不同。比如“订单金额”，销售说这是用户要付的钱，财务说这是含税金额要用来开票，运营说这是实付金额要用做业绩统计。如果这三个金额都放在一个 Order 对象里，那每一次口径调整都会引爆全链路。语言分裂往往意味着存在两个不同的上下文。
第二个是生命周期不同。一个概念在两个阶段受到完全不同的规则约束。比如客户在“售前咨询”阶段和“风控审核”阶段，虽然都是同一个客户，但关心的字段、行为规则完全不同。如果强行用一个 Customer 聚合承载所有阶段属性，代码会变成一个大杂烩。
第三个是变更频率和数据归属不同。两个团队以不同节奏改同一个模块，每次修改还要互相等发版，那说明组织边界已经暗示了上下文边界。这时候应该顺着组织边界去拆限界上下文，而不是靠技术手段硬拧在一起。
这不是理论推理，而是我踩过坑之后的总结。早期我把“用户”这个模型放在全项目共用，导致每个业务方都往 User 上挂字段，最终 User 表有上百个字段，谁都不敢动。按上下文拆开后，每个上下文只保留自己真正关心的用户属性，反而让模型清晰了。
2.4 一个库存场景的建模切片
用我最常讲的库存例子来说明限界上下文怎么切。库存这个词，在“销售上下文”里的含义是“可售库存”，用户能不能下单、能下几单，看的是可售数。而在“仓储上下文”里，库存是“实物库存”，入库、出库、盘点、移库，每一下都有实物动作。
这两个上下文关心的指标不同、更新方式不同。可售库存可能在下单瞬间就被预占，实物库存要等仓库真正发出货才减少。如果把它们建模成同一个库存聚合，每次需求变更都会让两边团队互相牵扯。
我们当时让两个上下文通过领域事件通信，销售上下文发出“订单已支付”的事实，仓储上下文消费后执行实际扣减。两个上下文各自维护自己的数据模型，互不直接访问对方的表。同时在销售上下文维护一个“可售库存读模型”，这个读模型只是仓储侧事件推送过来的投影，不承担实物库存的强一致性。
这个切法带来的直接好处是：后来库存策略调整了三次，仓储上下文的代码完全没有被动过。放在以前，任何库存改动都是一场横跨多团队的大上线。
3. 战术设计：聚合为什么经常变成数据库表的马甲
3.1 聚合边界：一致性优先，而不是外键优先
如果说战略设计决定系统的大骨架，战术设计决定代码能不能长期改得动。而战术设计里我见过最多的问题是聚合边界乱画。
最常见的错误是依照数据库外键关系“顺藤摸瓜”建聚合。客户有多少订单，就把 Customer 和 Order 放进同一个聚合：
java复制public class Customer {
private CustomerId id;
private List<Order> orders;
}
这个设计的理由是“客户和订单天然关联”。但聚合从来不是按照查询关联来划分的，它要回答的问题是：在这个业务用例里，哪些数据必须在一个事务内保持一致？
下单这个动作，会同时创建订单、更新订单行、计算总金额。这些才应该被放进同一个聚合。但客户资料和这个事没有一致性约束——客户可以同时下很多单，新增一个订单并不需要修改客户表的任何字段。把 Customer 和 Order 揉在一起，反而会让每次下单都去加载客户下所有订单，锁范围扩大，性能和并发双双受损。
我后来给自己立了一条设计标准：如果两个对象之间没有“不变量”需要在一个事务里同时满足，就不要放进同一个聚合。所谓不变量，就是业务在任何时刻都必须成立的规则，比如“订单总金额等于所有明细分摊金额之和”、“订单明细不能超过 50 行”。只有当某条规则跨越多个对象并且必须同步满足时，聚合才会变大。
用这个标准去审视，很多所谓的一对多关联根本不应该建模成聚合。一个发运单关联了多个发货行，这可以是聚合；一个用户关联了多个发货单，这就只是查询关系。
还有一个很容易犯的错，是为了性能把一个聚合拆得过碎，然后又用分布式事务硬拼。聚合越小，越需要更强的一致性保障。改聚合之前一定先问业务能不能接受最终一致，如果不能，这组模型就是该待在同一个聚合里。
3.2 仓储接口是给领域用的，不是给数据库用的
第二个高频问题是仓储被当成 DAO 的换皮。很多代码评审里我看到这样的接口：
java复制public interface OrderRepository {
Order findById(OrderId id);
List<Order> findByCustomerId(CustomerId customerId);
List<Order> findByStatus(OrderStatus status);
List<Order> findByCreatedAtBetween(Date start, Date end);
void save(Order order);
}
如果你定义了 OrderRepository，目的应该是“让领域层能按聚合根的方式存取订单”，而不是“给订单表提供所有查询入口”。findByStatus 这种泛查询本质上是在鼓励应用层绕过领域模型，直接按数据条件拉列表，业务规则又流回 Service。
我的调整方法很简单：仓储接口只保留按聚合根标识获取、保存、删除这几个操作。真正需要按条件查业务数据的地方，走单独的查询服务或读模型，领域层不关心数据最终落在 MySQL 还是 MongoDB。
接口立刻瘦身：
java复制public interface OrderRepository {
Order findById(OrderId id);
void save(Order order);
void remove(Order order);
}
刚开始团队会不适应，因为有人习惯把订单列表查询也塞进 OrderRepository。但当他们发现订单查询条件和订单状态规则经常调整，而这些调整完全不需要碰领域层时，那个边界优势就浮现出来了。查询属于“读场景”，可以随时优化索引、改 SQL、加缓存；聚合属于“写场景”，承载的是业务的一致性规则。两者纠缠在一起，等于让数据库细节反向污染领域逻辑。
3.3 应用服务与领域服务：不要把编排变成业务规则
分层代码里最容易被写成一锅粥的是 Service 层。表面上有 application/domain 两层 Service，但业务规则还是堆在应用层，领域对象依然是空壳。我之前就见过一个发票系统，开票规则全部写在 applicationService 里，两千多行，每次税率调整都要在那个类里找半天。
区分应用服务和领域服务，我的判断方式是这样：如果一段逻辑是为了“完成一个用户用例”而做的编排，比如开启事务、检查权限、调用外部服务、组织返回 DTO，那它属于应用服务。如果一段逻辑表达的是业务自身的规则，而且这个规则不太好塞进某个实体或聚合里，那它才属于领域服务。
举一个发票生成的例子。开票需要从订单聚合读取已完成支付的订单，从客户聚合读取开票抬头，从税率规则里算出含税金额。它跨了多个聚合，不适合放在订单里，也不适合放在客户里，这时候领域服务就出现了：
java复制public class InvoiceIssuer {
private final OrderRepository orderRepository;
private final CustomerRepository customerRepository;
private final TaxRuleRepository taxRuleRepository;
public Invoice issue(OrderId orderId, IssuerId operator) {
Order order = orderRepository.findById(orderId);
Customer customer = customerRepository.findById(order.getCustomerId());
Money taxAmount = taxRuleRepository.calculateTaxAmount(order.getProductLines());
return order.createInvoiceFor(customer, taxAmount, operator);
}
}
注意 InvoiceIssuer 里面没有事务、没有权限校验，也没有把明细数据转换成 DTO。这些动作留给应用服务去处理。领域服务只表达“这张发票是根据哪些规则算出来的”。代码讲的是业务语言，而不是数据库操作序列。
我当时重构那个两千行 applicationService 时，把税率计算独立成 TaxDomainService，把“订单是否满足开票条件”下沉到 Order 聚合内部，把“客户抬头能否变更”拆到客户对象里。最终那个瘦身后的应用服务只剩事务和控制流程，逻辑清楚到新人看一遍就能维护。
3.4 一次代码评审中的反例和后续重构
说一次真实的代码评审。同事给一个订单服务写过这样的方法列表：
text复制submitOrder
changeShippingAddress
applyRefund
issueInvoice
cancelOrder
syncInventory
exportOrder
updateOrderRemark
这个服务类把所有和订单沾边的事都塞进去了。为什么？因为它依赖了同一个订单状态机，大家都觉得“反正改的是同一个订单状态”。结果就是每次改退款状态时，都担心会不会影响发票里读到的订单状态。
我们当时花的力气不是去美化这个类，而是先重新描述业务：下单、改地址和取消订单，关心的是交易订单状态机；退款关心的是退款单状态机；开票关心的是财务事实状态机。这三者虽然在数据上共享同一个 OrderId，但它们各自服从的规则完全不同。
最后我们把订单拆成交易上下文、售后上下文、财务上下文，Order 对象在三个上下文里各自保留自己的模型。同步数据不是靠一个 Service 硬调另一个 Service，而是通过领域事件在上下文之间传事实。过程大概花了两周，重构完的代码总量没减少太多，但每个需求的影响范围缩小了至少 60%。这个收益是团队后来坚持领域建模的直接动力。
4. 和 AI 一起做 DDD：战略上还是要人来守门
4.1 AI 擅长生成“看起来像 DDD”的结构，但不理解业务边界
现在团队里越来越多人在用 AI 辅助写代码，也有人用它“写 DDD”。说法很好听，但我要给这句话浇一盆冷水：AI 非常擅长生成结构齐全的 Entity、ValueObject、Aggregate、Repository 代码，但它不会知道你的业务里“可售库存”和“实物在库数”是两个概念，也不会知道“退款申请时间”和“退款到账时间”不能被当成同一个字段。
原因很简单，这些边界通常只存在于业务专家的脑子里，需求文档很可能没有写。AI 没有亲历过那次库存超卖事故，不知道哪条规则是拿人力和赔偿换出来的。它可以给你一个代码骨架，但无法替代你与业务专家之间“持续质疑与确认”的过程。
所以我把 AI 定位成“结对草稿师”，而不是架构决策者。它可以快速把机械性工作做完，把人的精力留给真正需要判断的地方。
4.2 用 AI 做领域事件初稿，是一个高效启动动作
事件风暴的第一步是最难的，白板经常是空的。但 AI 可以在几秒内基于一段需求生成一版初步的领域事件列表。这个时候团队要做的不是接受它，而是拿着它去和业务专家对质。
我会用这样的提示词：
text复制你是一名领域驱动设计实践者。下面是一段业务需求，请提取候选领域事件清单，按业务时间顺序排列，统一使用过去时，并标出你认为语义有歧义的业务名词。
需求：用户可以在 App 发起订单退款，退款需要经过审核，审核通过后系统通知财务执行退款，退款完成后订单状态变为已退款，同时释放该订单占用的优惠券。
AI 通常能给出一个比较完整的初稿，比如：
text复制RefundRequestSubmitted
RefundRequestApproved
FinancialRefundExecuted
OrderMarkedAsRefunded
CouponReleased
它的价值在于降低启动成本，让团队不是在空白上硬想，而是直接做“删、改、合并”这三件事。这不是偷懒，用 AI 生成初稿的能力，帮我们把更多讨论时间留给了“这个词到底对不对”以及“这个事件是不是业务真实约束”。
4.3 用 AI 生成战术代码，必须把业务不变量写进提示词
我见过很多人的 AI 生成结果是华丽的垃圾：一类是大量 getter/setter 的贫血模型，一类是每个用例都做了一层抽象接口的重度设计。两者都很极端。
如果你只写“帮我生成一个 Order 聚合”，AI 倾向于给出一堆 setter。这时候要在提示词里明确四件事：聚合根是谁、有哪些业务行为、每个行为会改变什么状态、不能违反什么不变量。比如：
text复制请设计一个 Order 聚合根，包含订单状态、订单行、金额。
业务规则：
1. 只有状态为支付中的订单才能提交支付。
2. 订单明细最多 50 行。
3. 金额不能为负数。
4. 不要生成 setter，所有字段只能通过聚合根方法修改。
这样生成的代码，才更像 DDD 里面的聚合而不是数据容器。但就算如此，代码评审依然不能省。AI 可以保证语法正确，却很难判断这个聚合是否真的和业务规则一致、事务边界是否合适、和周边模型的职责是否重叠。
4.4 我不让 AI 替我决策“上下文怎么切”的原因
有一段时间我也试过把上下文划分的问题抛给 AI，希望它能给我一个“参考答案”。得到的结果要么太通用，要么缺少反例意识，从来不会主动问“你为什么把这两个规则放在同一个上下文”。它能做的更像是在复述主流 DDD 文章里的常见划分，而不了解你这个场景里哪一个隐性约束是真正不可妥协的。
建模看起来是产出图和类，本质上是在团队内形成一套关于业务边界的共识。如果我只是把 AI 生成的结果贴给大家看，讨论会停止，冲突会被掩盖。但那些冲突恰恰是建模过程中最有价值的东西：不同业务专家对同一个词的解释不同、对同一个流程顺序的理解不同，这些不一致才是系统复杂度的来源。人需要在场，去追问、去记录、去收敛。
5. 如果重新落地一次 DDD，我会按这个顺序推进
5.1 从建立术语表开始，而不是从架构图开始
如果让我带一个团队重新落地 DDD，第一件事不是画限界上下文大图，而是开一个简单的术语表文档。表头长这样：
| 术语 | 定义 | 出现上下文 | 易混词 | 负责人 |
|---|---|---|---|---|
| 可售库存 | 用户可下单购买的库存数量，下单时预占 | 销售上下文 | 实物库存、在库数 | 库存产品经理 |
| 退款单 | 用户发起退款后生成的处理单 | 售后上下文 | 退款记录、退款申请 | 售后产品经理 |
这个表不需要一次建完，而是在需求评审会上不断补。每当产品、开发对某个词理解不一致，就当场记录并指定负责人给出结论。两周后再看，术语表基本覆盖了项目里最容易出问题的那批动词和名词。
我之所以把这个排在第一步，是因为你后面无论怎么建聚合、怎么切上下文，都需要一套所有人都认账的语言。没有它，画出来的架构图很快会浮空。
5.2 选最小业务闭环做试点，不搞“一次建模全面铺开”
不要一上来就组织三十个人做一周的全面建模，那大概率产出一堆没人执行的大图。我更推荐选一个业务变化频繁、规则复杂的小闭环，先用完整流程跑通它，再用实际结果去说服团队。
一个合适的试点通常满足三个条件：第一，它有足够的业务复杂度，简单 CRUD 不行；第二，它在未来一个季度内有真实需求，能让模型马上接受考验；第三，它的业务专家愿意花时间参与讨论，这一点最关键。
试点的时间盒我通常会控制在三到四周。第一周完成事件风暴和上下文草图，第二三周完成核心场景的编码落地，第四周用来复盘哪里顺畅、哪里别扭。不要试图一次把所有战术模式都引进来，先把聚合、仓储、限界上下文跑通，后面再加事件或读模型都来得及。
5.3 判断 DDD 落地是否有效的标准是“规则改动成本”
很多团队做了 DDD，却只知道汇报“我们把代码结构改成了 DDD 四层”，这根本说明不了问题。我更在意的是几个追问：新增一条业务规则的改动范围变小了吗？修改订单状态判断逻辑时，还会担心发票和库存被误伤吗？业务专家看事件列表时，能读懂而且愿意点头吗？
判断标准不是“代码在 domain 包里”，而是“业务规则变化时，代码修改是不是只需要落在最小范围内”。如果改完一个需求，测试还是要回归全链路，说明边界并没有切对。如果一个规则从提出到上线，团队能明确说出它影响哪些聚合、哪些上下文，那 DDD 才算真正落地了。
我见过一些团队反向操作：技术部门觉得“我们业务复杂，必须上 DDD”，但业务场景其实是后台管理系统的列表增删改查。最后产出的不是领域模型，而是一堆为了 DDD 而 DDD 的抽象层，代码难读又难改。任何方法都有边界，DDD 不是替低复杂度代码兜底的万能药，工具要和问题匹配。
5.4 一句给后来者的实在话
这几年下来，我对 DDD 的理解已经和最开始很不一样。它不是一个“按目录分层就正确”的编码规范，也不是一套必须完整使用的成套框架。它是一套帮助你发现业务规则、并在代码里显式表达这些规则的方式。比起记住所有术语，能不能在业务专家说出一个模糊需求后，追问他“你说的这个状态到底意味着什么、和另一个状态冲突不冲突”，才是 DDD 真正要练的能力。
我现在做项目依然会先问自己：这个业务最复杂的地方在哪？如果答案是某个核心状态机或一大堆算钱规则，那就值得认真建模；如果答案是写个接口转发数据，那就别折腾 DDD。把精力投到真正需要领域理解的地方，剩下的麻烦自然会少很多。
写这篇文章的同时，我刚好在复盘一个新项目的上下文划分。和 AI 一起推演了好几轮事件列表，最后还是和业务同事关了会议室，用白板把几个经常混淆的词一条一条掰开揉碎，才算找到边界。DDD 的知识可以靠读，但是手感只能靠一次次这样面对真实业务去磨。希望这篇分享能让你少走一点我当年走过的弯路。