最近我在几个技术群和博客评论区里看到了一波很有意思的“回头翻案”式言论。有人翻出十二年前的帖子说“DDD本来就是给遗留系统改造用的你们拿来设计新系统是误用”有人说“DDD根本不是什么建模方法它只是分层架构的别名”还有人信誓旦旦地讲“真正的DDD必须用六边形架构不然就是假DDD”。这种叙述方式放在别的圈子里叫“岁月史书”放在技术圈子里就是有人开始按自己的需要重新编排领域驱动设计DDD的“正史”了。作为一个从敏捷开发火热年代就开始接触DDD、也亲手在几个中大型项目里落地过领域模型的从业者我想认真聊聊这件事。不是说不能批评DDD恰恰相反DDD身上有很多值得反思的问题概念门槛高、落地成本大、团队认知参差、被工程化包装后面目全非……这些都该骂。但“该骂”和“捏造历史”是两回事。当讨论变成罗生门新手很容易被带偏甚至带着错误的认知去设计系统最后把失败归结为“DDD不行”。这篇文章我不打算站队只想把几件我自己踩过坑、查过资料、见过真实案例的事情摊开讲清楚帮大家在这波“岁月史书”的声浪里找到一条能落地的判断路径。1. 先盘点一下这波“翻案”里都有哪些典型言论1.1 “DDD已死”和“DDD从未活过”每隔几年技术社区就会周期性出现“DDD已死”的论调。这个调调我见得很多了从2015年左右微服务刚火起来时被拿出来说一次到这几年的“云原生时代DDD过时了”套路几乎一模一样先找一个失败的团队案例再引用几段被截断的原书内容最后得出“DDD只能活在PPT里”的结论。最近的新玩法更进了一步直接“釜底抽薪”“DDD其实从来就不是一个具体的方法论它只是一堆概念的拼凑”。这种说法最难反驳因为它听起来很有“独立思考”的气质符合人们对“祛魅”的喜好。可问题是如果《领域驱动设计》那本书里那套关于模型、通用语言、限界上下文、聚合的理论不是方法论那什么才算方法论难道方法论必须要到“代码生成器”那个粒度才配叫方法论我倒不反对对DDD做“降格”处理——把它看作一套思维工具而不是银弹这恰恰是健康的。但“DISS不是问题否定其历史是另一个问题”。当一个人说“DDD从未活过”时他不是在参与技术讨论而是在做话语权的重置——因为他无法说服你DDD不好那就干脆让“DDD曾经被误解为很好”这件事本身变成笑话。1.2 “DDD本来就应该xxx”的重新发明比“已死论”更普遍的是各种“本来论”。典型句式是“DDD本来就应该配合事件溯源使用”“DDD本来就应该用六边形架构落地”“DDD本来就是要做CQRS的”……这种话术的高明之处在于它不否定DDD而是把你的实践经验全部判为“不入流”。比如你做了几年DDD用的还是经典的四层架构共享内核突然有人告诉你“没有用六边形架构的DDD不是真正的DDD”你心里是什么感觉你会先怀疑自己然后怀疑自己的项目最后怀疑那本书。但“本来论”最大的问题是缺乏文本依据。Eric Evans在《领域驱动设计》里通篇没有把DDD和任何一种具体架构风格绑定。他讲的架构是“模型驱动设计”下各层如何协作、如何保护领域层不被技术细节污染而不是“必须用端口适配器”这种具体处方。后者是后来无数实践者从工程教训中总结出的偏好把它们说成“DDD的定义”就是把实践经验偷偷升级成了教义。这种重新发明还有个副产品术语通胀。什么都可以叫DDD什么都可以说成“DDD的应有之义”。当所有人的DDD都不是同一个东西时圈子里的讨论就失去了公共基础。于是真正想学习DDD的人比算法工程师学新框架还累——因为框架文档是明确的DDD却没有“官方文档”只有一堆互相打架的二手解读。1.3 “用DDD失败的人都是没用对”还有一类言论我觉得要单独拎出来说。它诞生于“翻案”的反面走的是“原教旨主义”路线只要有人公开说DDD项目失败了评论区必然会出现“你们根本不懂DDD伪DDD当然会失败”。这套逻辑几乎是不可证伪的。它把所有失败都归咎于“没有用正宗DDD”但“正宗”的定义永远掌握在评论者手里。你说你做了事件风暴他说你没做领域分析你说你做了领域分析他说你的聚合设计是错的你问哪里错了他开始讲“这个需要长期咨询陪跑”。这种逻辑本质上和“岁月史书”是一枚硬币的两面都在用叙事替代事实用定义权替代证据。我见过真实的DDD失败案例也做过复盘失败的原因通常非常复杂组织架构与限界上下文冲突、领域专家缺席、团队代码能力不足、业务本身就在剧烈变化……把这些统统推导到“因为没学正宗DDD”上既不符合事实也不负责任。2. 六边形架构是怎么被“焊死”在DDD战车上的2.1 六边形架构的真正生日既然热词里带着六边形架构那这大概就是最近“岁月史书”事件的重点战场了。先把历史事实摆出来六边形架构Hexagonal Architecture也叫端口与适配器架构是Alistair Cockburn在2005年前后提出的起因是他在实践中发现业务逻辑不该被数据库、UI、消息队列这些外围技术绑架。那个年代还没有“微服务”这个词DDD蓝皮书刚刚出版两年两者是完全独立的思想脉络。六边形架构早期最知名的实践者是写《企业应用架构模式》的Martin Fowler那一派他们当时在讨论“业务逻辑与技术细节分离”时引用的是《企业架构模式》中的“Application Facade”和“Domain Model”和Evans的DDD并没有强绑定关系。那问题来了为什么现在一说DDD默认配图就是那个经典的“六边形内部领域模型外部端口”的图这就要说到DDD落地史上的一个尴尬事实Evans在书里提出的经典四层架构用户界面层、应用层、领域层、基础设施层在实际工程中非常难拿捏。尤其是“基础设施层依赖方向倒置”这个点大多数人做不到一做就做成“Controller调Service调Repository”领域层变成一堆贫血对象的文件夹。2.2 当“分层”撑不住时六边形被当成了救生圈我在第一个真正规模比较大的DDD项目里就踩过四层架构的坑。当时我们严格按照书里的分层做了包结构controller、service、domain、infrastructure分得清清楚楚代码评审时大家都很满意。但等业务复杂起来问题立刻浮现一个应用服务经常需要编排多个仓储事务边界落在哪一层消息发不出去要不要回滚外部API调用超时领域事件到底算不算已发布这些问题四层架构没有明确答案团队开始各自为政。后来我们引入了六边形架构的思路——把入口和出口都抽象成端口把数据库、消息队列、HTTP客户端都当作适配器替换。这么一改领域层干净了不少测试也变得好写了。那段时间我们确实在内部达成了共识“DDD项目就该这么搭”。但这里有个重要的认知陷阱我们是“因为DDD遇到了工程问题所以选择了六边形架构来辅助”而不是“六边形架构是DDD的前提”。可多数博客在传播时把第二个表述当成了事实。于是“DDD六边形”从“经验组合”变成了“标准范式”最后升级为“不用六边形就不算DDD”。这本质上就是一次典型的术语漂移事件。2.3 捆绑叙事为什么这么有市场我后来想明白了这种捆绑叙事有它不可抵挡的传播优势它给了学习者一个“标准答案”。DDD最让人痛苦的地方就是“答案全靠自己悟”。限界上下文怎么划聚合怎么做大做小这些没有唯一正确的解让习惯了框架文档的工程师非常没有安全感。六边形架构恰好提供了一种“看起来有标准”的结构端口、适配器、内部六边形边界清晰目录结构一目了然。当有人说“这就是DDD的标准落地方式”时很多人会本能地选择相信——因为相信让自己舒服。然而标准答案的代价是牺牲灵活性。六边形架构本质上解决的是“技术细节与业务核心的隔离问题”它根本不关心你的领域模型质量。一个完全没有领域模型的CRUD项目照样可以用六边形架构套得严丝合缝。反过来一个领域模型极其精妙、但采用传统三层架构的项目也不会因为没用六边形就失去“DDD资格”。把两者焊死对双方都是伤害。我个人的结论是你可以把六边形架构和DDD配合使用这没有错现实中也确实很好用但你应该清楚你是在“用DDD建模再用六边形架构做代码组织”不是在做“标准DDD”。放弃“标准答案”的执念反而更容易用好这两样东西。3. 翻开蓝皮书那些正在被悄悄掉包的“原厂定义”3.1 “通用语言”不是词汇表是协作协议“岁月史书”最精细的操作就是把原书概念掉包成另一个看似相似、实际完全不同的东西。“通用语言Ubiquitous Language”就是重灾区。流行解读里通用语言被简化成了一张“团队术语表”业务管订单叫“工单”技术管它叫“Order”大家统一一下就叫“Order”吧。表面看这就是通用语言的全部。但Evans写这个概念的时候强调的是在一个限界上下文内业务专家与开发人员使用同一套语言进行讨论、建模、设计而且这套语言必须体现在代码、测试、文档、日常对话中。被简化成词汇表之后通用语言的核心动作——深入的、能暴露模型分歧的对话——被完全丢掉了。团队可能拥有一份术语表但做需求分析时依旧各说各话建出来的模型跟业务真实心智模型严重背离。这是一种特别隐蔽的“岁月史书”它没有篡改文字却篡改了概念的生命力。3.2 “模型”不是只画UML是要进入代码的第二个被掉包的概念是“模型”。好多翻案文章喜欢嘲讽DDD——“画一堆UML图就能解决复杂业务吗”这个靶子很好打因为确实有很多伪DDD项目热衷于画图。但原书的立场恰恰相反。Evans反复强调模型必须“和实现绑定”要让它成为“软件的脊柱”。一个只存在于PPT里的抽象模型在他看来不是DDD的成果而是失败。他在前言里就写得很明白这本书讲的是“如何在软件中建立模型”而不是“如何画好一张模型图”。可惜的是太多实践者以及批评者把“建立模型”理解成了“绘制模型”。这也解释了为什么有些“翻案”看起来很犀利——他们批判的对象本身就不是DDD而是伪DDD。但他们偏要沿着“伪DDD就是DDD”这条线去完成对DDD的宣判这就把批判做成了新的历史叙事。3.3 贫血模型与充血模型被夸大的对立讨论DDD永远绕不开“贫血模型vs充血模型”而这场讨论里也充斥着我见过最多的掉包。流行观点是DDD推崇充血模型使用贫血模型就是没有领会DDD精神甚至“贫血模型是一种反模式”。这个观点源自有据。Martin Fowler写过一篇著名的《AnemicDomainModel》批评了那种“对象只有getter/setter业务逻辑全散落在Service里”的贫血模型。这篇博客对DDD圈影响极大。但这里有个细节被岁月史书淹没了Evans在他的书里并没有明确批判贫血模型他讲的是“模型承载业务规则”这个原则。如果一个贫血模型配合服务层仍然能让业务规则的语义清晰可见、由领域层统一表达那它并不必然违背DDD。现实情况是很多项目因为团队的代码能力、业务规模、历史包袱用“贫血对象事务脚本”的方式反而更清晰。你可以说这不是DDD的最理想形态但把它直接打成“异端”等于把原书没有的教义塞进了历史。3.4 战略设计为何总是缺席最后想认真提一句所有翻案声音里很少听到有人认真讨论战略设计。“限界上下文”“上下文映射”“防腐层”“共享内核”“开放主机服务”这些属于Evans原书后半部分的内容才是DDD相对其他建模方法最有价值的部分——它试图解决“多模型共存”“系统边界”的问题。但战术设计聚合、值对象、领域事件、仓储因为更贴近编码成了培训机构的卖点、博客的流量入口。狼来了喊多了“DDD建聚合画领域事件图”的矮化版本反而成了主流。这变成了一种双重的岁月史书一边是战术设计被拔高成全部一边是战略设计的缺席被默认为正常。等到有人说“DDD解决不了系统边界问题”时你甚至不知道他说的“DDD”到底是指原书里的DDD还是那个被矮化过的DDD。4. 假DDD泛滥才是岁月史书真正的土壤4.1 “建文件夹”式DDD最流行的实践幻觉这几年的项目里我见过特别多的“DDD项目”说它们是“建文件夹”式DDD一点都不冤枉。它们的特征是包结构严谨地按照application/domain/infrastructure三层划分领域层里躺着一堆实体和一些表面上的值对象然后就没有然后了。聚合内没有业务不变量领域事件量是零规则散落在应用服务里所谓“领域服务”只是替Controller分担了十行代码。遇到这种项目团队复盘时会觉得惊讶“我们严格按照DDD做的为什么代码还是烂”项目最终失败团队把责任推给DDD。但这里面有个特别反直觉的真相DDD的许多概念确实是“听着简单、做着极难”的。我自己的团队第一次做聚合划分时信心满满地划分了十几个聚合结果两个月后就发现了模型漂移——同一个业务规则在两个聚合中各实现了一版。如果你没有经历这种“被模型教训”的过程你很难说自己在实践DDD。4.2 失败复盘里的归因错误当大量“建文件夹式DDD项目”失败后翻案文章就有了现成的素材。它们会把这些失败的复盘当作“DDD项目的失败”进而推导“DDD不适用于xxx场景”。但稍微仔细看一眼就能发现那些项目里根本没有像样的领域建模过程——没有事件风暴级别的业务探索没有核心域和支撑域的区分没有限界上下文的独立演进。这种归因错位很有意思一个人开车路线图拿反了车子半路抛锚他不怪自己没检查油量、不怪自己看错地图而是得出结论“这条路根本不通网上那些说这条路能到的人都是在骗人”。然后他开始写帖子把这条路的真实地理坐标全部“修正”一遍。这就是岁月史书的生成机制不是历史本身被歪曲而是提取历史样本的过程充满了偏差。4.3 伪DDD为什么会成为主流叙事我不愿意把所有锅都扣在培训机构和自媒体头上因为需求是双向的。学习者在面对复杂业务时确实需要一套能快速上手的“骨架”而“DDD就是用六边形架构建四个文件夹”这个骨架是市面上最容易理解的简化版。它牺牲了DDD最有价值的“模型驱动”内核保留了最容易展示的外壳。但这种简化一旦形成生态就会被大家默认为“DDD的事实标准”。等有一天原教旨主义者站出来说“你们这些根本不是DDD”双方就会开始互抛历史。一边说“DDD本来就是这样教的”一边说“DDD从来不是这样定义的”。吵到最后没有人去翻开那本书没有人去看真实项目的演进只剩“谁的话术更像权威”。这也是为什么我觉得“岁月史书”这个现象本质上并不是恶意造谣而是技术传播中“简化-固化-神圣化”的必经之路。警惕它是因为它会污染你独立判断的参照系。5. 面对岁月史书一个实践者的自处方式5.1 观点是廉价的文本是硬锚点碰到任何关于“DDD本来应该怎样”的说法我的第一反应就是你说的“本来”出处在哪Eric Evans的《领域设计》是第一手文本Vaughn Vernon的《实现领域驱动设计》是优质的扩展读物Alberto Brandolini的事件风暴方法论和Greg Young的CQRS/ES都是后来被实践证明有效的补充但它们有各自的文献出处和语境。当你发现一个人把上述所有来源都混在一起说成“DDD本来如此”时你就该知道这是一锅被人为搅匀的史书而不是一本有章节页码的科学著作。这里分享一个特别实用的技巧给自己建一张“概念出处表”。同样是“聚合”Evans怎么说、Vernon怎么扩展、你在项目中怎么落地各占一列。当你读到一篇新博客时把它的观点放到表格里对照很快就能看出作者是在转述原书、还是在补充个人经验、还是在创造“传统”。这个方法不复杂但能过滤掉绝大多数只有情绪没有依据的翻案文。5.2 识别“岁月史书”话术的三个红旗红旗一绝对化定义。只要出现“真正的DDD必须……”“DDD本质上就是……”这类句式先警惕。定义权是历史叙事权的浓缩一个健康的术语讨论应该是“在xxx语境下我认为比较好的一种落地方式是……”。红旗二动机可疑的归因。“只要用了DDD就是失败”“只有用了DDD才配叫复杂业务架构”两种极端都值得怀疑。技术决策是多因素博弈的结果任何单一归因都可能是为了叙事服务的。红旗三凭空消失的失败细节。翻案文章往往把失败项目的关键细节处理得很模糊团队规模、领域复杂度、业务语言统一程度、技术团队能力基线这些信息要么缺失要么被严重简化。这些细节才是复盘的灵魂删掉它们故事就开始变成史书。5.3 把DDD和它的合作伙伴解耦反而更好用我想把“DDD、六边形架构、CQRS/ES、微服务”这几个常常被焊死的概念拆开来它们之间是“可以协作”的关系不是“必须配套”的关系概念解决的问题与DDD的关系DDD业务复杂性建模与模型落地核心方法论六边形架构技术边界隔离与技术细节解耦可选实现风格CQRS/ES高并发读写分离与溯源审计可选的读写模型策略微服务部署独立性与组织自治战略设计的一种落地载体我自己在项目中就做过非六边形的DDD落地方案也见过CQRS跟DDD毫无关系的纯数据平台项目。解耦后每个概念各自承担职责反而更容易判断业务建模累了问题出在DDD的战术设计边界层依赖混乱了去调整六边形架构的端口性能扛不住了再考虑CQRS。如果所有问题都记在“DDD”帐上你既解决不了问题也对不起DDD。5.4 我的建议去写自己的“战场记录”而不是参与“历史定稿”防“岁月史书”最好的方式不是你成为一个更会吵架的评论者而是成为一个勇于公开细节的实践者。我在团队内部推行过一个很小的做法每个迭代结束时在技术周报里花两三百字记录“模型在这个迭代发生了什么变化”——聚合是否拆分、限界上下文之间是否新增了合作方式、哪些通用语言的词汇在实践中被替换了。这些记录弥足珍贵因为它们记载的是“模型与真实业务的反复对冲”而不是某篇文章里那个光滑圆润的“最佳实践”。当团队后来面临架构质疑时我们不需要引用任何权威文章只需要把这些记录摊开就能说清楚“这个设计决定是怎么来的当时面对什么约束后来效果如何”。这就是你自己的“正史”。说到底DDD最大的敌人从来不是所谓的“新范式”而是那些为了获得确定性而强行收编历史的声音。一个领域、一种方法论只有允许不同经验共存、允许失败细节被讨论、允许文本解释被挑战它才可能真正活下来。我不指望能帮谁画出一条绝对正确的DDD路线但如果这篇东西能让你在下一次听到“DDD本来应该……”的时候多问一句“这句话的出处在哪里、这位作者的上下文是什么”那它就没白写。方法论一旦被神圣化就会开始腐朽。保持一点考古学家的怀疑精神对DDD、对六边形架构、对所有被包装成“正统”的东西都保持一点距离反而能走得更远。
