张云雷宝宝近两年只要聊到后端架构，DDD（Domain-Driven Design，领域驱动设计）几乎是一个绕不开的词。招聘 JD 上写着“熟悉 DDD 者优先”，技术分享会上有人拿着聚合根讲得眉飞色舞，代码评审时动不动就有人提一句“你这个设计不够 DDD”。我也曾经跟风啃过《实现领域驱动设计》，在项目里硬着头皮落地过几回，但折腾下来，我对 DDD 的态度从最初的兴奋，慢慢变成怀疑，最后落到“不喜欢”三个字。这篇文章不是来抬杠的，也不是劝你别学 DDD，而是想站在一个普通后端开发者的角度，聊聊我在实际项目中踩过的坑，以及为什么对一个被捧上神坛的方法论，我始终保持警惕。
如果你正在纠结团队要不要引入 DDD，或者你在面试时被问“你怎么理解 DDD”但心里其实犯嘀咕，那这篇文章可能比那些讲“聚合根怎么建”“领域服务怎么划”的教程更值得读——因为我要聊的不是 DDD 的理论怎么用，而是它到了真实业务里，到底是怎么一步步变成团队负担的。
1. 先说说 DDD 真正有价值的地方
说实话，DDD 并不是一无是处。我见过它在某些场景下确实发挥了巨大作用，只是这种作用往往被过度夸大，导致很多人以为它是银弹。我最早接触 DDD 是在一个传统的电商订单系统里，那时候系统已经跑了好几年，代码里全是几百行的 Service 方法，一个订单状态逻辑散落在七个文件里，改一个需求要牵扯三四个团队。当时我们请了一位外部顾问，他引入的第一件事不是画各种图，而是拉着产品、运营、研发一起做了几天事件风暴（Event Storming），把整个订单履约流程从头到尾捋了一遍。
那次梳理给我的震撼挺大的。我们发现很多业务规则其实一直藏在代码里，没人真正说清楚过。比如“退款申请后库存什么时候回补”，我们代码里是异步任务做的，但产品以为是一瞬间完成的；又比如“订单取消后优惠券到底返不返”，三个月前改过一版规则，但文档没更新，测试用例也没覆盖到。DDD 的“通用语言”和“限界上下文”这两个概念，在那一刻确实帮了大忙——它逼着业务方和技术方坐在一张桌子上，用同一套术语描述问题，而不是各说各话。
所以如果你问我 DDD 有没有价值，我的答案是：有价值，但它的价值主要在分析阶段，而不是编码阶段。 事件风暴、统一语言、限界上下文梳理，这些思维工具能帮你把混乱的业务理清楚。团队如果业务复杂度高、规则多变、领域专家就在你身边，这套东西确实值得一试。但问题也恰恰出在这里——很多人把“分析阶段的思维工具”直接等同于“编码阶段的架构标准”，于是麻烦就开始了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 我不喜欢 DDD 的几个真实原因
2.1 通用语言成了团队内部的“黑话制造机”
DDD 最核心的理念之一是建立通用语言（Ubiquitous Language），让业务术语在代码里、文档里、讨论中保持一致。听起来很美对吧？但实际执行起来，它往往会从一个良好愿望，变成一套只有少数人听得懂的密语。
我参与过一个项目，团队花了整整两周时间给领域术语做定义。我们把“客户”拆成“客户”“会员”“用户”“账号”四个概念，每个都有严格语境；把“订单”分成“主订单”“子订单”“交易单”“支付单”；连“商品”都要区分“SPU”“SKU”“商品模板”“销售品”。理论上这些区分都有道理，确实对应不同的限界上下文。但问题是，团队里不是所有人都是领域建模专家，新来的同事看代码注释根本看不懂，连产品经理自己都经常用错词。
更麻烦的是，通用语言一旦固化到代码结构里，就变成了束缚。有一次产品提了个需求，说要给“客户”增加一个“是否允许赊购”的标记，按我们当时制定的术语规范，“客户”和“会员”是两个不同概念，这个字段放哪边争议了半天。最后为了遵循“通用语言”，我们把一个简单需求拆成三个服务、两次异步同步才做出来。而放到以前，可能就是在用户表里加一个字段的事。
这让我意识到一个问题：通用语言应该服务于沟通，而不是反过来绑架沟通。 为了术语纯正而增加系统复杂度，在我看来是本末倒置。DDD 的拥趸会说“那是因为你们建模没建好”，但现实是大多数团队根本没有资源、没有时间也缺少足够的领域专家去“建好的模”。我见过太多团队把两周时间花在术语定义上，最后产出物就是一堆没人维护的 Word 文档和一张过时两周的上下文映射图。
2.2 建模与代码之间，隔着一道很难跨过的鸿沟
DDD 的另一个核心主张是让代码模型和领域模型保持一致，也就是“模型驱动设计”。理论上，你应该能从代码直接看出业务规则。但实际开发中，业务规则从来不是静态的。市场在变、政策在变、老板的想法也在变，领