【技术变迁脉络解析】领域驱动设计（DDD）：一场精心策划的“设计邪教”

最新推荐文章于 2025-11-28 22:53:16 发布

原创最新推荐文章于 2025-11-28 22:53:16 发布 · 962 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#ddd #设计模式

特色系列专栏收录该内容

4 篇文章

订阅专栏

文章目录

前言
一、概念能够升华体系
二、入门第一步：学习一门新的黑话
三、战术设计：把“Hello World”写成一部史诗
四、CQRS：让我们把读写分开，然后……更混乱了
五、事件风暴（Event Storming）：用便利贴淹没整个会议室
六、D不D的D的，有啥区别么
七、尴尬局面
八、总结
后记
参考文献

今天我们来聊聊一个在软件开发界如雷贯耳，却又让无数英雄好汉折腰的名词——DDD。

前几年接触到了DDD，开始看着很有新意，大家的教程都玄之又玄，感觉是mvc的下一代设计模式，但是所有的文章都是在讲概念，没有一篇有实际案例，甚至连示例代码都没有。后来经过众多博主的摸索，逐渐有了一些示范，仍然没有可应用的目录结构。深入研究之后觉得至少在国内开发没有什么价值，就放弃了。

前段时间再看到的时候已经成初步规模了，昨天看到一篇吐槽的文章，写的很好，基于此再次吐槽一下。

前言

在软件开发的江湖里，总有一些技术名词，它们的光环大于实效，它们的黑话多于代码。它们让初学者不明觉厉，让老油条会心一笑，更让那些能拍板决策的非技术领导心驰神往。

在这片黑话的修罗场上，牛B的人物早已厌倦了中英文混杂。他们更进一步，熟练运用中英文缩写，对普通人进行降维打击。而最顶级的玩家，则擅长造就新名词，并成功将其科普出去，成为行业“圣经”。

有几项技术，我从心底里鄙视和厌恶，但每次在技术方案中，都默默的把它们加进去，而且给足了它们分量。因为它们对于方案的成功与否，起着重要的概念性指导作用。

它们就是中台、低代码，以及DDD。这三个不同领域中的技术，肩负着同样的责任，那就是往死里忽悠。这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和CTO的最爱。也是咨询类公司的最爱。

这些玩意儿，有的可以忽悠大公司，有的可以忽悠小公司，反正谁也别想逃掉。

但毒瘤如果能够为我们带来利益，当然也要拥抱。不要那么死板嘛。

当妖风袭来，比起关上窗子，我们要拥抱它，要投其所好！为什么有的人工资高，有的人升的快！有的人成为了大师！要从根本上想想原因。

一、概念能够升华体系

你知道么？越是职位高的人，越容易喜欢虚无缥缈的东西。拿古代的皇帝来说，有很多期望与神仙相会的，就被方士骗的死去活来。即使到最后知道被骗了，也只能偷偷的把消息封锁起来。最近看《资治通鉴》，就发现了很多这样的案例。

一来，是他们真的有这种需求；二来，是怕这些事被曝光了丢脸，只能咬牙坚持下去。

地球上没有新鲜事，放到软件行业也一样。当我们把一件东西给神化，赋予它某些超自然的能力，它就能在方士的路上越走越平坦。

如何神化？抓痛点、谈愿景、搞方法论，一般就能够销售成功。

当然，销售成功只是第一步，我们还要避免失败，避免被秋后算账。所以，我们需要把决策者的积极性调动起来，让他认识到自己的不足，羞于承认自己的弱点，我们就算落稳脚步了。只要决策者上了船，他就会想方设法美化它，争取更多的资源，让更多的人上船。

为什么互联网黑话生命力强劲，就是因为它能忽悠，能够升华你的思想，而不是空洞洞的代码。

我这里举个例子。

有一家公司，由于研发的人数有限，但是活儿很多，分散在多个系统之间。研发部门研究出来的结论是：要聚焦，集中力量到核心系统上。怎么办？不能在PPT上干巴巴的写上聚焦两个字吧，那显得多LOW。

思来想去，突然灵机一动。要不，我们造点名词吧。按照级别，分它个CVP系统、IVP系统、EVP系统。这样，一下子逼格就上升了不少。

看不懂这些名词？看不懂就对了，因为这是我造的，要的就是看不懂这种效果。

看看下面这张图，我们甚至可以赋予它属性，把系统归类到这三类之中。

重要的是，业务系统的聚焦，摇身一变，成为了CVP的重点建设。哈哈，比起一句话就完事的决策，我们这下可以聊很久了。

“教你怎么说话十分钟，等于什么都没说”。这是一种非常重要的能力。

那么，我们就来看一下，这些技术到底是什么？为什么是毒瘤？为什么要拥抱它们。

二、入门第一步：学习一门新的黑话

在这里插入图片描述

你想学DDD？很好，请先背诵并理解以下咒语：

领域（Domain）：你做的业务。好的，这很直白。
子域（Subdomain）：业务的一部分。嗯，也能理解。
限界上下文（Bounded Context）：好了，开始上强度了。它大概意思是“在这堵无形的墙里面，我们说一种特定的黑话”。比如，在“订单”上下文里，“客户”可能只是一个ID和地址；在“客户管理”上下文里，“客户”就是有姓名、电话、爱好的活生生的人。本质上，它就是让你理直气壮地造轮子，美其名曰“解耦”。
实体（Entity）：有ID的东西。比如用户。
值对象（Value Object）：没ID的东西。比如用户的地址。为了区分它俩，你可能需要开一场半小时的团队讨论会。
聚合根（Aggregate Root）： “黑帮老大”。你想动它手下的小弟（实体/值对象），必须先通过它。这导致了你在修改一个看似简单的字段时，可能需要先加载一个包含几十个关联对象的庞然大物到内存里，然后庄严地调用 aggregateRoot.changeSomething()。性能？那是运维要考虑的事情，我们只关心设计的“纯洁性”。
领域服务（Domain Service）：当某个操作实在塞不进实体或值对象时，我们就会创建一个“领域服务”。说白了，它就是一个收留“无家可归的业务逻辑”的收容所。

当你终于搞懂了这些术语，并能在会议上流利地使用它们时，恭喜你，你已经成功了一半——至少听起来像个专家了。

三、战术设计：把“Hello World”写成一部史诗

让我们来看一个经典的DDD实践场景：“用户修改自己的昵称”。

普通程序员的写法：

UPDATE users SET nickname = '新的昵称' WHERE id = 123;

搞定，收工。干净利落。

DDD程序员的做法：

创建一个 User 实体，包含 userId、nickname 字段，并提供一个 changeNickname(newNickname) 方法。这个方法内部会进行业务规则校验（比如昵称不能有敏感词）。
创建一个 UserRepository 接口，定义 findById 和 save 方法。
实现 UserRepositoryImpl，里面可能是JPA、MyBatis之类的ORM映射。
在应用层，你要写一个 ChangeNicknameCommand 和 ChangeNicknameCommandHandler。
在Handler里，你需要：
- userRepository.findById(command.getUserId()) // 先把用户聚合根请出来
- user.changeNickname(command.getNewNickname()) // 庄严地调用领域方法
- userRepository.save(user) // 再把整个聚合根存回去（即使只改了一个字段）
为了这点事，你可能创建了：1个Entity，1个Repository接口，1个Repository实现，1个Command，1个CommandHandler，1个Service…

原本一行SQL能解决的问题，现在你需要10个类，跨越N层，进行一次完整的数据库往返。这就好比你想在墙上钉个钉子，DDD会让你先设计一台通用机器人，它能识别钉子、墙壁，并具备安全锤击协议，最后才执行“钉钉子”这个动作。

四、CQRS：让我们把读写分开，然后……更混乱了

当你觉得上面的“聚合根”查询慢得令人发指时，DDD的信徒会向你推荐“圣杯”——CQRS（命令查询职责分离）。

“简单来说，”他们眼神发光地说，“写模型用一套，读模型用另一套！”

于是，你的系统架构变成了这样：

写端：依然坚守着那套繁琐的“加载聚合->调用方法->保存聚合”的仪式。
读端：直接写SQL查询视图或者专门建的查询表。

结果就是：你维护了两套模型，两套逻辑，还要处理它们之间的数据同步问题（通常通过事件总线）。一个简单的需求，现在需要在两个地方修改。复杂度指数级上升，就为了优化那个本来可以很简单的查询。

这就像是因为觉得开车去楼下超市买东西停车麻烦，于是你决定：以后出门一律叫直升机。但你忘了，你只是去买包薯片。

五、事件风暴（Event Storming）：用便利贴淹没整个会议室

这是DDD的“需求分析”阶段。一帮人（产品、开发、测试）被关在会议室里，对着满墙的彩色便利贴，试图用“事件”来描绘整个业务流程。

“用户已注册！” —— 贴一张橘色的。
“订单已创建！” —— 再贴一张。
“支付已失败！” —— 贴一张红色的。

几个小时后，整面墙变得像抽象派艺术画。所有人都头晕眼花，但内心充满了“我们深刻地理解了业务”的虚假成就感。然而，当大家回到工位，面对代码时，依然会发出灵魂拷问：“所以……我们刚才在便利贴上讨论的那个‘库存已锁定’事件，到底该由哪个聚合根来发布？”

六、D不D的D的，有啥区别么

所谓领域驱动，就是根据需求设计系统，这句话本来就是废话。

有Demo代码没？

所有的文章下面，都充满了这样的发问。如果说DDD层只是战略上有用，那它就不应该进入程序员视野，它应该是需求分析师的玩具。DDD应该学学TOGAF、COBIT、CGEIT之类的培训，把眼光放在战略布局上，不要老是想着革程序员的命，搞什么战术。

你要是专心搞搞业务培训证书，你赚你的钱我做我的架构设计，咱们井水不犯河水。但你要把触角伸到我的领域，就会招来像我这样的喷子。

DDD正确的打开方式，就是拥抱它的战略阶段，完全扔掉它的战术阶段。这样做，你会活的很舒坦。原谅我使用“限界上下文”这样的名词来解释一下：你只要把我的服务边界划分清楚了，你管我后面是怎么实现呢，设计模式和架构模式，我的工具箱多的很，并不缺CQRS、事件溯源这样的名词。

DDD的概念最早来源于2004年，这么多年没火，没有标准落地，不是没有原因的。最近几年，有些人发现了技术名词的贫瘠，重新捡起了它，希望它能继续为KPI效力。

我曾痴迷DDD，被它的美好愿景折磨的兴奋无比。买了网课，买了书籍，到最后发现它在浪费我的时间。我恨它。恕我直言，一个难度高，落地难的技术方案，根本没有资格让人分割精力去了解它。

不好意思，没有路转粉。

首先，搞DDD的，都是些卷中卷公司，它不像微服务技术一样，能够找到大量落地的方案。实际上，你几乎找不到任何有价值的参考示例，更别说这些示例之间还相互打脸。它就像是圣经一样，给你说什么是对的，但怎么做，全靠你悟。

为什么你干不了DDD，你的团队干不了DDD？DDD给出了三个主要原因。

对团队的要求较高。画外音，你做不好是你的团队不行
只有复杂的业务使用DDD才能见效。那什么是复杂呢？并没有定论。话外音，你觉得不好用，那是你的业务不够复杂
虽然你用不了DDD，但其中的思想，还是值得借鉴和思考的。画外音，我是万金油，不会让你白学
没有人会承认自己的团队不行，没有团队会承认自己的业务简单，没人能忍受自己的投入就真的肉包子打狗了。DDD通过几个让你不能打脸的理由，瞬间将你绑在了一起。

2020年，花了整整三个月时间，有幸拜读了《实现领域驱动设计》这本书，对其深厚的文字运用水平惊叹拜服。以后，即使一个简单的CRUD项目，我也知道文档应该怎么写了，这本书就是非常好的案例。

你搜一下DDD的文章，不论什么文章，都有一个特点，那就是不能好好的说人话。所有的应用代码，都是一堆无法说服人的垃圾代码。因为开发者和正常的写法一比较，发现自己在找罪受，那为什么要用它呢？

就拿吹的很牛b的六边形架构来说吧。

六边形架构，因为长得像蜂窝，看起来就很靠近绿色的自然界，很高大上。说实话，我到现在都没弄明白六边形架构，八边形架构（没这种东西），三角形架构（没这种东西）之间，到底有何区别，这群名词狂魔为啥选择了6这个数字。

您就直说，复杂的业务逻辑，不应该过多的关注技术等基础设施、但要预留接口就行了，非要整的这么玄乎，一条条蚯蚓一样的线从那腐烂的六边形上辐射出来。觉得很美么？或许老板真这么觉得，因为它像彩虹一样的名词轮，确实能唬住一群蹉B。

不要说ServiceMesh的数据平面和控制平面分割，是靠DDD指导的哦，虽然它概念上靠的上。

下图是google搜索Hexagonal Architecture出现的一张图。

哎吆，六边形呢？这图怎么整了个10边形？那还是六边形架构么？您忽悠小孩子呢？当我不识数？什么，你又把它叫做洋葱头架构，它们不是一个东西？这样的误解在DDD中比比皆是，我也不想解释，因为它们都是短话长说。这说明了它是一门全面的忽悠方法论，是靠堆概念和黑话起家的，宣传者也不合格。

整个DDD这一套概念，价值观就有问题。或者说作者的本意或许是好的，面向的是复杂业务。结果让这群宣传者和培训一捣鼓，就成了解决问题的必要手段。

但是不好意思，您连起码的顺畅交流都没整好，没资格教别人做架构。

七、尴尬局面

让人觉得尴尬的是，真正需要DDD的人，并不认同它；不需要DDD的人，被强迫认同它。

DDD最大的价值是梳理业务性需求，将不同的业务领域划分出来，并形成领域之间的接口交互。说个实话，我见过很多咨询公司的大佬，他们对这种想要通吃的方法论嗤之以鼻，更倾向于使用TOGAF之类老牌的业务梳理方法。但条条道路通罗马，最终的领域划分还是能够达成一致。

这些梳理的过程，大部分是业务专家，以及系统架构师的范畴。他们的工作成果，将作为输入输出到技术团队实现。他们需要DDD，但他们并不用。

相比较而言，DDD的战术阶段，毫无价值而言。比如，把数据汇总到宽表或者大数据中心，形成数据“中台”提供交易域、管理域、查询域的分离，我并不需要知道什么CQRS的概念，也能工作的很好。至于实体充血不充血，我本来就是微服务了，业务粒度本来就很小了，要怎么写是我的自由，改造也是我自己的成本，我并不需要按照你那一套来。谈业务和技术的沟通？不好意思，不能沟通而去做业务的团队，我还没见过。

工程师被决策层强迫使用DDD战术书写业务，结果代码更乱，更改更加频繁。但是DDD说，不好意思，不是我的错，是你团队不行。

道理是这个道理，但在现实中，还是有人吹嘘、甚至使用这个东西去改造代码。《微服务架构模式》这本书，甚至有事件溯源和CQRS两个章节，去专门讲解DDD的一些落地的内容。这叫做大师毒害了大师，当然也叫做相互扶持。

恕我直言，如果你信了这些鬼话，大概率会把项目带入死亡。尽信书不如无书，架构是一种权衡，并没有通吃的指导思路。你可以参考，可以思考，但就是不能照搬，因为每个公司的技术前提都不一样。

话虽如此，但当一些概念被吹嘘起来的时候，你不去拥抱它，反而会产生问题。软件行业有两个难题，一个是怎么把复杂的事情简单的汇报，另外一个就是把简单的东西搞复杂。对于前者，主要是描述你构想的可行性。而对于后者，主要的目的就是让人觉得很高大上，很主流，越晦涩越好。前者脚踏实地，后者口吐莲花。

而后者的功效，显然要比前一种有效得多。让人听上去感觉很牛x，但是听不懂，可以获得掌声，也可以体验高高在上的感觉。没人会承认自己的智商不在线，你需要激起这些人的活力。只要有人认同，就可以产生利益。

有些概念，有些人，并不是神，但利益共同体，需要他成为神。这玩意也有信徒，你信么？但软件设计的工具，难道不是合适就用，不合适就扔么？为什么会成为信徒？仅仅是因为上船了而已。

朋友们，在一定程度上，DDD这些概念，与比特币之类的概念，并没有什么区别。这就是信仰的魔力，这就是大师的力量啊！