我不喜欢DDD：一个后端开发对领域驱动设计的落地反思与务实建议

近两年只要聊到后端架构，DDD（Domain-Driven Design，领域驱动设计）几乎是一个绕不开的词。招聘 JD 上写着“熟悉 DDD 者优先”，技术分享会上有人拿着聚合根讲得眉飞色舞，代码评审时动不动就有人提一句“你这个设计不够 DDD”。我也曾经跟风啃过《实现领域驱动设计》，在项目里硬着头皮落地过几回，但折腾下来，我对 DDD 的态度从最初的兴奋，慢慢变成怀疑，最后落到“不喜欢”三个字。这篇文章不是来抬杠的，也不是劝你别学 DDD，而是想站在一个普通后端开发者的角度，聊聊我在实际项目中踩过的坑，以及为什么对一个被捧上神坛的方法论，我始终保持警惕。

如果你正在纠结团队要不要引入 DDD，或者你在面试时被问“你怎么理解 DDD”但心里其实犯嘀咕，那这篇文章可能比那些讲“聚合根怎么建”“领域服务怎么划”的教程更值得读——因为我要聊的不是 DDD 的理论怎么用，而是它到了真实业务里，到底是怎么一步步变成团队负担的。

1. 先说说 DDD 真正有价值的地方

说实话，DDD 并不是一无是处。我见过它在某些场景下确实发挥了巨大作用，只是这种作用往往被过度夸大，导致很多人以为它是银弹。我最早接触 DDD 是在一个传统的电商订单系统里，那时候系统已经跑了好几年，代码里全是几百行的 Service 方法，一个订单状态逻辑散落在七个文件里，改一个需求要牵扯三四个团队。当时我们请了一位外部顾问，他引入的第一件事不是画各种图，而是拉着产品、运营、研发一起做了几天事件风暴（Event Storming），把整个订单履约流程从头到尾捋了一遍。

那次梳理给我的震撼挺大的。我们发现很多业务规则其实一直藏在代码里，没人真正说清楚过。比如“退款申请后库存什么时候回补”，我们代码里是异步任务做的，但产品以为是一瞬间完成的；又比如“订单取消后优惠券到底返不返”，三个月前改过一版规则，但文档没更新，测试用例也没覆盖到。DDD 的“通用语言”和“限界上下文”这两个概念，在那一刻确实帮了大忙——它逼着业务方和技术方坐在一张桌子上，用同一套术语描述问题，而不是各说各话。

所以如果你问我 DDD 有没有价值，我的答案是：有价值，但它的价值主要在分析阶段，而不是编码阶段。 事件风暴、统一语言、限界上下文梳理，这些思维工具能帮你把混乱的业务理清楚。团队如果业务复杂度高、规则多变、领域专家就在你身边，这套东西确实值得一试。但问题也恰恰出在这里——很多人把“分析阶段的思维工具”直接等同于“编码阶段的架构标准”，于是麻烦就开始了。

2. 我不喜欢 DDD 的几个真实原因

2.1 通用语言成了团队内部的“黑话制造机”

DDD 最核心的理念之一是建立通用语言（Ubiquitous Language），让业务术语在代码里、文档里、讨论中保持一致。听起来很美对吧？但实际执行起来，它往往会从一个良好愿望，变成一套只有少数人听得懂的密语。

我参与过一个项目，团队花了整整两周时间给领域术语做定义。我们把“客户”拆成“客户”“会员”“用户”“账号”四个概念，每个都有严格语境；把“订单”分成“主订单”“子订单”“交易单”“支付单”；连“商品”都要区分“SPU”“SKU”“商品模板”“销售品”。理论上这些区分都有道理，确实对应不同的限界上下文。但问题是，团队里不是所有人都是领域建模专家，新来的同事看代码注释根本看不懂，连产品经理自己都经常用错词。

更麻烦的是，通用语言一旦固化到代码结构里，就变成了束缚。有一次产品提了个需求，说要给“客户”增加一个“是否允许赊购”的标记，按我们当时制定的术语规范，“客户”和“会员”是两个不同概念，这个字段放哪边争议了半天。最后为了遵循“通用语言”，我们把一个简单需求拆成三个服务、两次异步同步才做出来。而放到以前，可能就是在用户表里加一个字段的事。

这让我意识到一个问题：通用语言应该服务于沟通，而不是反过来绑架沟通。 为了术语纯正而增加系统复杂度，在我看来是本末倒置。DDD 的拥趸会说“那是因为你们建模没建好”，但现实是大多数团队根本没有资源、没有时间也缺少足够的领域专家去“建好的模”。我见过太多团队把两周时间花在术语定义上，最后产出物就是一堆没人维护的 Word 文档和一张过时两周的上下文映射图。

2.2 建模与代码之间，隔着一道很难跨过的鸿沟

DDD 的另一个核心主张是让代码模型和领域模型保持一致，也就是“模型驱动设计”。理论上，你应该能从代码直接看出业务规则。但实际开发中，业务规则从来不是静态的。市场在变、政策在变、老板的想法也在变，领域模型需要不停地演进。

问题是，代码模型一旦建立起来，是有惯性和重构成本的。你今天画了一张漂亮的聚合根图，明天产品说“这个状态要加一个分支”，你发现这个改动会波及四个聚合根；后天业务方又改了口径，你画的上下文映射图已经跟实际代码差了十万八千里。这时候摆在面前的路只有两条：要么放弃模型，直接在代码里打补丁；要么花大力气重构模型，让代码跟上新认知。而真实项目里，绝大多数人都选了第一条路。

我印象很深的一次经历，是我们严格按照 DDD 设计了一套基于事件溯源的订单领域模型，每个聚合根都有自己独立的事件表，状态变更全部通过事件流回放。设计文档漂亮得一塌糊涂，演示的时候大家都说好。结果上线三个月后，业务方提了一个需求：订单要支持“部分发货后再拆单，且拆出来的子单可以独立退款”。这个需求放在传统设计里，可能就是一个状态机加几张关联表的事。但在我们的“纯正 DDD”模型里，这意味着事件流的语义要变、聚合根的边界要调、事件表的补偿逻辑要加，前后折腾了三周。

如果 DDD 的模型真的像宣传的那样“能跟上业务变化”，那这种改动不应该这么痛苦。但现实是，任何一个方法论在落地时都要面对现实的摩擦力，而 DDD 的摩擦力尤其大，因为它的建模成本高、重构链路长、对团队整体水平要求极高。

2.3 “战术模式”成了过度设计的遮羞布

如果你在技术社区搜 DDD，看到最多的内容是各种战术模式：实体（Entity）、值对象（Value Object）、聚合（Aggregate）、领域服务（Domain Service）、工厂（Factory）、仓储（Repository）、领域事件（Domain Event）……这些模式本身没有错，但在很多团队里，它们被当成了 KPI 一样的存在。

我见过一个 Java 项目，整个团队只有三个人，做了一个内部报表系统，总共不到二十张表。但架构上愣是整出了四层：Controller 层调 Application Service，Application Service 调 Domain Service，Domain Service 里再包一层 Repository 接口，Repository 接口又包了几层实现。每个实体都要建一个 Value Object 去包装主键，聚合根的 update 方法里加了各种业务规则校验。CRUD 写起来要翻五个文件，改一个字段要动三个类。你要是问为什么要这么设计，答案一定是“DDD 就是这么分的”。

这种情况太常见了。很多人把 DDD 当成了架构的最终答案，而不是把它当成一种分析工具。 实际上 DDD 那套战术模式最早是从 Eric Evans 的《领域驱动设计》里提出来的，目标是为了解决复杂领域模型的表达问题，而不是给所有项目套上用不上的“骨架”。当时书里白纸黑字写着，如果领域足够简单，直接用 CRUD 就行了。但这句话被绝大多数人选择性忽略了。

从我观察到的现象来看，DDD 的战术模式特别容易被两类人滥用：一类是经验不足、刚学会几个概念就想炫技的新人，另一类是陷入“架构洁癖”、凡事都要追求理论正确性的资深开发。第一类人能把简单问题复杂化，第二类人能把复杂问题变得更复杂。两拨人凑到一个项目里，代码的体积和复杂度指数级上升。

2.4 落地成本与团队门槛被严重低估

我不想否认 DDD 在一些大型、复杂、长周期的业务系统里确实能带来收益。但收益的另一面是成本，而这个成本经常被忽略。

首先是人力成本。DDD 要求团队里有能推动领域建模的人，这个人既要懂业务，又要懂技术，还必须有极强的抽象能力和沟通能力。现实里这种人是稀缺的，往往一个部门也就一两个，而且他们通常已经在管理岗上了。剩下的人里，能搞清楚聚合边界、事件一致性、最终一致性这些概念的，掰着手指头数得过来。一个团队如果想真正落地 DDD，往往不是一两个高手带几个新手就行的，而是需要所有核心开发都能达到一定水平，否则写出来的代码就是四不像。

其次是时间成本。DDD 的建模不是一次性的，而是一个持续的过程。每接手一个新需求，你都要回到领域模型里审视一番：这个改动是应该落在现有聚合里，还是新建一个聚合？两个上下文之间的通信是用领域事件还是应用服务直接调用？这些讨论是好事，但它极端耗时。一个本来一两天能排期的需求，因为要“符合领域模型”，可能要多开两次评审会、多写几份设计文档。

还有基础设施成本。纯正的 DDD 落地往往依赖事件驱动、CQRS、事件溯源、消息队列这些东西，否则领域事件和最终一致性就无从谈起。这意味着技术栈要升级、中间件要引入、运维要跟上。对一个中小团队来说，这些成本是实打实的，但收益却不一定看得到。

我并不是说这些成本不该花，而是说在投入之前，你得想清楚：你的业务真的复杂到需要这种级别的建模吗？你的团队能支撑这种级别的协作吗？你的项目周期允许这种级别的讨论吗？如果答案里有一个“否”，那 DDD 大概率会变成一顶不合尺寸的帽子，戴着难受，摘下来又怕人说你不够“先进”。

3. 当 DDD 变成负担：落地变形的五个典型信号

既然说了不喜欢，那就干脆把话讲透。根据我自己的经历和观察，如果一个团队强行上 DDD，通常会出现下面这些变形信号。如果你所在的团队也出现了类似情况，我建议你停下来想一想，我们到底是在做 DDD，还是被 DDD 做。

第一个信号是“术语定义永无止境”。这其实很讽刺，DDD 强调的是通用语言，但当通用语言本身变成了争论对象，它就失去了意义。我见过一个团队为了定义“结算单”和“结算记录”是不是同一个东西，争论了一下午，最后也没争出个结论。这种争论对业务没有任何帮助，只是满足了大家对“表达精确性”的执念。

第二个信号是“简单功能复杂化”。正常情况下，一个查询用户订单列表的接口，Controller-Service-DAO 三层就够了。但在“DDD 化”的代码里，你要先经过 Application Service，然后调 Domain Service，Domain Service 里还要先通过 Repository 取聚合根，再调用聚合根上的查询方法，最后把实体转成 DTO。每一步都合情合理，但加在一起就显得极其笨重。我的经验是，一个接口的调用链如果超过四层，就要警惕了。

第三个信号是“重构代价被无限放大”。DDD 的模型强调聚合边界和业务不变量，这本来是好东西。但业务一变，聚合边界往往跟着变。而在高度耦合的模型里，改变一个聚合的边界可能牵连几十个类。每次调整都像动一次大手术，项目节奏因此被拖慢。

第四个信号是“代码里充满间接层”。我见过一个项目，Repository 接口和实现类中间还有一层抽象仓储，理由是“将来可能要支持多种存储”。但实际上项目上线三年了，存储一直就只有一种。这些为了“可扩展”而提前造的轮子，本质上是过度设计。

第五个信号最隐蔽，也最致命——团队水平的“高坡效应”。在这个模型里，真正理解全局的永远是那一两个主架构师。其他人只是被动地在一个个小角落里“填代码”。一旦架构师休假或者离职，整个系统的演进就停摆了。DDD 从来不是一个人的游戏，但它很容易变成“一个人的游戏，其他人围观”。

4. 如果不用 DDD，我们应该用什么？

我不喜欢 DDD，不等于我主张所有项目都回去写大泥球。我的看法是：大多数项目需要的不是 DDD，而是清晰的分层、明确的边界和足够的工程纪律。 下面是我自己目前比较倾向的一套做法，不一定适合所有人，但至少它更轻、更务实，容错率也更高。

4.1 用“业务模块”而不是“限界上下文”划分边界

限界上下文是 DDD 里一个很有价值的概念，但它的划分方式往往需要较强的建模功底。在实践中，我发现用更朴素的“业务模块”来划分边界，效果反而更好。一个模块对应一组高内聚的业务功能，模块之间通过接口通信，内部自己管理自己的数据。比起限界上下文，这种方式更直观，团队也更容易理解。

比如一个电商系统，你可以拆成商品模块、订单模块、库存模块、支付模块、营销模块。每个模块有自己的数据表、自己的服务接口、自己的内部实现。模块之间不能直接查对方的表，只能调接口。这种做法虽然没有 DDD 那么“优雅”，但至少边界是清晰的，而且模块的粒度可以根据团队规模灵活调整——人少就粗一点，人多就细一点。

4.2 用“消息解耦”而不是“领域事件”处理跨模块协作

DDD 里的领域事件要解决的核心问题是“跨聚合的一致性”。这个概念很好，但落地时往往要引入消息中间件，还要处理最终一致性、幂等消费、事件回溯等一系列复杂问题。

对我的大多数项目来说，更务实的做法是：如果两个模块之间的协作是同步强一致的，就直接用接口调用 + 本地事务；如果是可以异步的，就用消息队列解耦，但不给这些消息起名叫“领域事件”，只需要保证“发出去的消息最终能到达目的地”。用消息中间件，自己控制重试与补偿。

这么做的原因很简单：消息就是消息，不需要给它加上“领域”二字才显得高级。该同步就同步，该异步就异步，别为了贴合某种模式而强行给消息做分类。我的经验是，一旦引入“领域事件”这个概念，团队就会开始思考哪些事件是“领域内”的、哪些是“集成”的，反而凭空增加了沟通成本。

4.3 保持贫血模型，但给 Service 一层“业务语义”

DDD 拥护者经常批判“贫血模型”，认为模型里只有数据没有行为，业务逻辑全堆在 Service 里。我过去也认同这个批判，但现在我反而觉得，对绝大多数系统来说，贫血模型加薄得恰到好处的 Service 才是最稳妥的选择。

悲观一点说，大部分系统的业务规则没那么复杂，复杂的是各种外部依赖和边界条件。与其费劲巴拉地把业务规则塞进实体里，不如保持实体只是数据的载体，把业务逻辑写在 Service 里。但这里有一个关键技巧：Service 不能变成单纯的一堆散乱方法，它需要有一层“业务语义”。

举个例子，同样是更新用户信息，你可以写一个 updateUserInfo(userId, phone, address)，这在贫血模型里没问题。但更好的做法是写一个 changeUserProfile(userId, newProfile)，然后在方法内部检查字段变更、记录操作日志、触发送消息。这种方式既不要求你把方法放进实体类里，又能让代码读起来有业务味道。说白了，系统架构要的不是“模型多丰满”，而是“改动时多安全”。

4.4 面向接口编程，但不为未来过度抽象

我见过很多被 DDD“洗脑”的人，写代码时满脑子都是“这个接口将来可能有其他实现”，于是每个类都抽了接口，每个接口都多加了一层。但真实的情况是，等你真正需要扩展的时候，你没有上下文，重构也来得及。

更务实的态度是：只有在你已经拥有两个以上不同实现，或者明确知道第二个实现会在短期内出现时，才去抽接口。 否则就老老实实写实现类。这不是不讲究设计，而是在平衡复杂度和成本。可维护性不是靠抽象的数量堆出来的，而是靠代码的可读性和变更的局部性堆出来的。

我自己现在写代码，会尽量遵守一个原则：一个需求改动时，最好只涉及一到两个文件，最多不超过三个。如果改一个需求要动六个文件，那不管是 DDD 还是别的什么架构，都说明设计有问题。

5. 如果团队非要上 DDD，我的折中建议

写到这里，可能有读者会说：“道理我都懂，但公司已经决定要推 DDD 了，我怎么办？”这种情况我也经历过，胳膊拧不过大腿。如果你碰巧也处在这种局面里，我这里有几个务实的折中建议，不求你爱上 DDD，但至少别让项目被拖垮。

5.1 只做战略设计，不做战术设计

DDD 可以分为战略设计和战术设计。战略设计包括限界上下文、上下文映射、通用语言，这些偏分析和规划；战术设计则是实体、值对象、聚合、仓储这些偏编码的实现模式。

我的建议是：战略设计可以认真做，战术设计要克制。 换句话说，可以在项目初期组织事件风暴，把核心业务流程梳理清楚，确定各个模块之间的边界和依赖关系；但不要强求代码里必须出现聚合根、值对象、领域服务这些结构。模块边界清晰了，代码里用传统的三层结构反而是最优解。

这种方案的好处是：你能拿到 DDD 在“分析层面”的红利，让业务和设计对齐，同时避免掉进战术模式的泥潭。我见过一些团队用这种方式落地，效果比全盘 DDD 好得多，至少代码读起来不像在做脑外科手术。

5.2 选一个核心域实践，不要全面铺开

DDD 里有个概念叫“核心域”（Core Domain），指的是业务中最关键、最独特、最能产生竞争优势的部分。如果你真的要实践 DDD，建议只选一个核心域做试点，而不是把整个系统全部“DDD 化”。

比如在电商系统里，订单履约可能是核心域，但用户注册、短信通知、后台报表这些支撑性功能，用 CRUD 就够了。让最复杂的那块业务用上领域建模，其余部分保持传统方式，风险和收益都更可控。

我见过最离谱的案例，是把登录注册模块都做成了“领域模型”，用户名和密码这种简单的数据存储也被包装成了实体加仓储。这种形式主义除了让代码变难读之外没有任何价值。

5.3 统一语言要轻量，不要教条

统一语言是一件好事，但别让它变成团队的负担。我建议的做法是：在某个模块的代码里，类名、方法名、变量名尽量跟业务方常用的叫法保持一致。比如业务方习惯叫“退款单”，代码里就别叫“ReverseOrder”。这种命名层面的对齐成本最低、收益最大。

但如果团队非要对每一个术语做严格的定义、画映射表，甚至为了用词开会，那我劝你赶紧喊停。通用语言的目的是让沟通顺畅，不是让沟通变成一场学术审查。 如果写代码的人、测试的人、产品经理聊需求时大家都能听懂，语言就已经“通用”了。

5.4 警惕“为了事件驱动而事件驱动”

前面说了，纯正的 DDD 常常依赖事件驱动架构。但事件驱动本身是一把双刃剑。它把同步的调用变成了异步的消息，解决了耦合问题，却引入了一致性、可观测性、消息积压、重复消费等一堆新问题。

我的原则是：如果你的系统暂时没有性能瓶颈和强解耦需求，就老老实实用同步调用，别为了 DDD 而上消息队列。 事件驱动不是不能上，但要上得明明白白——明确知道它解决了什么问题，也明确知道它带来了什么新问题。如果一句“DDD 就是要用领域事件”就说动了你，那项目迟早会被这个消息中间件坑。

6. 复盘：我踩过的最痛的三个坑

写一篇“不喜欢 DDD”的文章，如果不把自己踩过的坑拿出来晒晒，说服力就不够。我这里选三个印象最深的，每一个都实打实浪费过我和团队的时间，希望对你有警示作用。

第一个坑是“把领域模型当成需求文档”。我们当时花了好几周做事件风暴，把整个流程画得清清楚楚，大家都很兴奋。结果模型一画完，所有人就觉得“设计已经完了”，代码随便写写就行。实际情况是，模型画得越漂亮，代码里“不匹配”的地方越多。后来我把这些图翻出来对比实际代码，发现当初的模型已经和现实脱节得面目全非。模型是探索的工具，不是交付的终点，这句话是花了几周时间买来的教训。

第二个坑是“过度追求聚合的纯正性”。我们在一个项目里为了把“订单”和“订单项”放在同一个聚合里，把所有订单项都跟着订单一起加载。数据量一上来，性能直接崩了。后来一查，很多订单根本不需要加载全部订单项。我们不假思索地遵循“聚合内强一致”的教条，却没有想清楚什么场景真正需要这种强一致性。理论是死的，数据是活的，性能是最诚实的。

第三个坑是“领域事件泛滥”。一开始我们只用领域事件处理跨模块通知，后来每个小状态变更都要发个事件，系统里各种事件的发布和订阅关系比蜘蛛网还密。排一个乱序问题，要顺着消息链路捋十几个事件主题。后来我们做了一个“事件瘦身”，只保留真正核心的业务事件，一下子世界清净了。少即是多，这个道理在事件设计里尤其成立。

7. 我的最终想法

回到标题：我为什么不喜欢 DDD？我最想说的话是：我不喜欢的是那个被神化、被教条化、被当成万能方案的 DDD，而不是那个强调“关注业务”的 DDD。

DDD 的核心思想——从业务出发、建立统一语言、划分模块边界——这些我举双手赞成。我反对的，是把它变成衡量程序员的标尺，变成项目中说不得的“政治正确”。一个方法论的最终目的应该是帮助团队更好地交付软件，而不是成为团队自身的负担。

在我个人看来，选择架构方案跟买鞋是一个道理。鞋子再好，不合脚也白搭。DDD 就是那双看起来特别专业、特别高端的登山鞋，但团队如果只是平时在平地上走走，穿它只会磨出一脚水泡。最终适合你的，可能是那双轻便舒服的跑鞋——不那么“高级”，但能陪你走更远的路。

如果你现在正准备在团队里推 DDD，我劝你先问问自己三个问题：业务复杂度真的到了非上 DDD 不可的地步吗？团队里有人能承担起持续建模的重任吗？公司能接受因架构调整带来的短期效率下降吗？如果三个问题里有一个犹豫，我建议你先从模块划分和统一语言做起。这些属于 DDD 的“低垂果实”，见效快、风险小。等这些做到位了，如果还觉得不够，再考虑要不要把聚合、领域事件这些“重型武器”搬出来。

最后再分享一个我自己的小原则：技术选型时，如果某套方案“听起来很完美”，但团队里没人有成功落地经验，那它大概率是个坑。真正的靠谱，是把项目平稳交付、把代码写得让人愿意维护、让新同事两周内能接手。这些朴实的标准，比任何方法论都重要。

我已经很久没在项目里用 DDD 了，但我会继续关注它的发展。说不定哪天业务真的复杂起来，我会再次翻开那本书，重新试一试。但在那之前，我更愿意把精力花在把眼前这一亩三分地种好——毕竟，好的架构不是靠某个方法论堆出来的，而是一行行代码、一次次重构、一个个不眠之夜磨出来的。