DDD 为什么火不起来？

[Hanggi]

DDD 贴链接：维基百科

最近隐约能听到有人谈起 DDD，或者有人尝试 DDD 之类的话题。

DDD 作为一种架构模式，无关何种语言或者框架，但是真正为 DDD 而设计的框架或者以 DDD 为吸引点的框架几乎找不到。

与此相类似的还有 Graphql，虽然出来了也没有多少年，也并没有特别流行，但至少会发现很多服务端框架都开始支持 Graphql 了。

DDD 到底有没有用，到底有谁在用 DDD 模式呢？

[avichen]

业务太复杂，没那功夫按照 DDD 拆，能按时交付已经不错了。

[gravelbit]

美团有的部门是有在使用的

[poorcai]

所以现在都是什么模式啊？小白疑问

[love]

看到几个模式的理由是“因为这样可以更容易的替换实现”
不好意思，绝大部分项目一个功能点只有一个实现。。。你要替换？直接在这个实现上面改不就完事了

[Hanggi]

@love 是的，我也看到过类似的说法。
有一个例子，好像说一个项目要从 mongodb 迁移到 mysql，但是不想一口气换掉，而是逐步换掉，所就用 DDD 模式，为同一个功能提供 mongodb 的底层和 mysql 的底层。但不知道后来怎么样了。

[rioshikelong121]

前戏太复杂了。

[matrix67]

DDD 有啥现成的项目可以参考学习学习

[matrix67]

@matrix67 #7 awsome ddd 自问自答

[chendy]

DDD 需要非常了解业务，说白了就是对团队要求高
一般的团队很多时候并没有足够的时间和精力去做这件事情，都是一把梭做出来就完事

[k9982874]

pm：等我改完需求看你再怎么 d ？

[WispZhan]

DDD 只有在“梦之队”，你才有机会实践。

它是一整套完整的开发方法。如果你的团队注重方法论，并且起点高，大牛多。那么它非常适合你。否则，够你喝一壶。从需求分析、设计建模、开发实践都在它的涉及范围内。

不管是对 BA 还是 DEV 要求都很高。 普通野鸡团队就别想了。

[lhx2008]

主要还是因为 WEB 开发 CRUD 一把梭，Service 一把梭，全是面向过程的东西，并不需要 DDD

[ConradG]

就像楼上说的，不说 DDD，真正算得上遵循面向对象设计的项目都少的可怜。

[Midnight]

DDD 优势很明显，缺点也很明显，DDD 配合 BDD 属于长线投资，就目前国内的状况做短线居多，别说 DDD 了，就连完整走 TDD 都没多少

[optional]

DDD 传统业务更适合。 互联网业务一是多变，二是关注性能关注细节， 上层调用 API 都要考虑成本，DDD 就不太适合了。

[LokiSharp]

因为你的所处的行业局限于互联网公司

[passerbytiny]

门槛太高，绝大多数人用不起。但是不要看不火就别不当回事，刘德华现在的火爆程度已经比不上流量明显或网红了，但一出面后者就得让位。

[charlie21]

阿里盒马领域驱动设计实践
https://www.infoq.cn/article/alibaba-freshhema-ddd-practice

[zclHIT]

从我进入公司之前公司就在各个交付的项目中使用 DDD 了，当我开始写代码之前 TDD 就已经是公司开发的标配技能了。。。hmmmm 。。。。

[railgun]

我一直在实践，Deadline Driven Develop

[huijiewei]

DDD 不光需要开发专家，还的配一个领域专家。

[ericgui]

@railgun +1

[ShareDuck]

@railgun 太真实

[Hanggi]

@zclHIT
你们真的有严格执行 TDD 吗？还是说只是开发每个同能同时写对应的测试。

我说的严格执行是指 “红-绿-重构” 的循环。感觉做着做着很容易变成，先写个功能，然后写个测试，看看这个函数对不对。

[baiyi]

成本太高，DDD 只靠着一个架构师是做不成的，它需要全团队的人都会，还要有领域专家

[qinxi]

怎么实现我不管,明天我就要

[bobuick]

DDD 是套方法轮，目前落地没有特别具象又适合普罗大众的实践。让它就更接近只是套方法论思想这方面的理论上了

[SjwNo1]

今晚讨论一下需求，明晚上线

[asaxing]

@Hanggi 确实是先写测试，遵循

[asaxing]

@asaxing 红绿重构，但不是所有人都这样做，个人觉得有三分之一会 TDD，有些组会强制 TDD，就算如此还是有很多关于 TDD 的讨论，支持反对的人都很多

[chenuu]

我大二左右就听人说过 ddd,现在毕业快三年了,也没有实际用过.

[chanchan]

太多东西就像减肥药

[MrJing1992]

工作快 7 年了，没有见过有公司用单元测试或者 TDD，DDD 就听过阿里系用得多

[leoskey]

标准的 DDD 需要花费更多精力难以落地。对于小项目来说，可以用简化的 DDD 快速搭建。

[niubee1]

客户大爷太急躁，老板太急躁， 不会给你 D 的时间的

[putin541]

DDD 应用到一个类的粒度，成本有点高，其实微服务架构也算是 DDD 的一种实现。

[guolaopi]

“明天能上线不？”

[kkeiko]

DDD 不是技术问题，是业务问题

[CoderGeek]

瞎 D 时间成本太高 有水平理的清楚的少 但是吹得飞起 TDD 、DDD

[exploreXin]

领域驱动设计可以看成是产品设计阶段更高级的一种构建方法论，产品设计是什么？说白了就是做东西的时候要提前规划好，在概念阶段就把可以规避的风险全都规避掉，避免出现摩天大楼盖了 100 层，才发现地下有溶洞，再建楼就会塌了，只能全部拆掉的情况出现。而保证产品设计阶段的产出成果，最重要最突出的两个方面，就是产品把关人和项目时间。时间比较好理解，只有充裕的时间，才能打磨出好的流程，好的产品概念，3 个月的项目让三天做出来，这样的项目哪有时间推行 DDD，根本不可能的。

另一方面，产品把关人是什么？产品把关人就是我们所说的产品经理，概念上面的所有东西，什么可以做，什么要做但是现在还不适合做，什么功能做了会增加用户，什么做了会减少用户，这都是产品经理需要负责的。产品经理有一个特点，就是门槛低，但是成长难度大，产品经理的成长曲线和方式和程序员是完全相反的，程序员的岗位是门槛高，但是只要入门了，并且稍微努力一下，成长难度会比产品经理低很多。这样的事实导致一个问题，就是产品经理岗位重要，工资高，但是门槛低，就有很多能力不行但有看到产品岗位工资超高的人，站到了这个岗位上，什么概念管理，质量管理，都不会，画个原型丢给开发，这就是工作日常了，这样的能力水平是没办法驾驭高级的产品开发方法论的。所以有这样低水平的产品把关人，也不奇怪为什么我们很少就见到 DDD 了。

就算产品经理能力超高，懂得如何推行 DDD 工作方式与流程，但是要知道 DDD 的精华其实不完全在技术团队，DDD 能否推行起来，一大半还要看有没有领域专家和技术团队对接，提供领域知识，领域专家也是产品把关人。领域专家是啥？就是你的软件开发完，所要投放到的环境中，对系统逻辑最熟悉的那个人，啥意思？说白了，就是银行软件，领域专家就是银行的业务经理，医院的软件，就是医院里的院长之类的人物，开发的软件起源于领域的实际需求，而需求最初是从领域专家那里获取的，获取之后的需求输入到产品经理那里，产品把关人把整理之后可以实际开发的需求交到开发，之后的测试，部署，运行，最终的软件，又回到领域，帮助领域工作，这是一个逻辑闭环，所以产品方面，光有开发团队的产品经理是远远无法使用 DDD 的，还要有领域内的资深人士，领域专家是团队外的产品把关人。所以注定只有金融，医疗，政府类的影响大，规模大的大型软件系统开发，才会用 DDD 这种复杂的开发流程，小公司哪有经历找领域专家，有些小企业连产品经理都没有，更不用说别的了，小企业的第一目的不是盈利，而是活下来，活下来才有后面的事情。

另外提一点，就算有能力与领域内的人物对接，也不一定有领域专家，很多非 IT 的组织内部也是极其混乱的，根本没有一个或者少数几个人可以对整个内部业务逻辑搞的很明白，所以找不到领域专家这样的人物存在，这个也是 DDD 推行难的一方面原因。

所以可以看出 DDD 是一种降低问题复杂度的方法论，是否推行 DDD 要看软件对应的问题是否复杂到一般方法无法解决的程度，而不是想要用一个新技术尝尝鲜而强行推广，那样的话，就是扔掉苍蝇拍，搬出大炮来打蚊子了，大炮固然厉害，但是无法完成消灭蚊子的问题。

[as5739]

DDD ？段艺璇？（逃

[miniwade514]

领域模型，很多产品经理都未必能说得清楚，做技术的还是不要瞎琢磨了。今天设计完了，明天就得跟着需求改。谁给你时间瞎折腾呢……

[zclHIT]

@Hanggi 我们不仅坚持完整的 TDD，在项目中还在坚持 pair programming：）

[zclHIT]

简单的介绍一个在实践 DDD 过程中发现的优点，在 DDD 中我们划分了领域，构建了领域内部的模型，当我们去和 BA or PM 沟通方案的时候，大家有了一个观点一致的模型之后，沟通业务的速度明显快了起来。不至于在“名字类似但含义不同”的概念之间来回切换，不断确认我说的 A 是不是就是你理解的 a 这样一类的问题。

[abcbuzhiming]

把现实问题抽象成业务模型，本身要求的难度就不低，DDD 这种更高级的抽象，要求就更高，要求高的东西，都很难推广的

[ConradG]

微服务任何意义上都算不上 DDD 的实践。
微服务的出发点是方便系统的迭代（改需求）和在整体层面增加稳定性。
DDD 的出发点是扫除业务需求和代码实现再到具体实施之间的障碍。

虽然有人说微服务的划分借鉴了 DDD 的上下文边界概念，这只能到有相似的地方。但你不能说 C 语言和英语都用拉丁字母所以 C 语言是英语的实践。

以及 DDD 不一定需要“独立”的领域专家，也不一定非要用于复杂业务系统。

[visonme]

之前写 Net 时候接触比较多，总体感觉 DDD 不是不火，而是大多数项目 /业务系统没到上 DDD 的必要，强制落地，后期负担太重。

[janyw]

1.业务没复杂到一定规模不需要，上了反而拖后腿。
2.DDD 是个思想，和设计模式一样，每个人的理解不一样，没必要非得套用，无招胜有招。
3.在我的理解中 DDD 是规范，需要至上而下遵守。

[davidyanxw]

@janyw 👍
1. 小公司用不上，大公司或者复杂业务才有场景，业务复杂到一定程度，组织架构不会简单，人事问题会成为这类技术架构或者业务架构很大的阻碍；
2. 确实是一种设计模式，属于思想维度的东西。量化或者标准化有难度。给执行带来了问题。
实际中，业务精通 ddd 思维弱的人 vs 业务熟练思维强的人，前者更吃香也有话语权。
客观上，会导致 ddd 落地很难。
3. 属于思想维度，需要可落地的规范。
上车是否排队，属于规范；是否尊老爱幼，属于思想。
前者可以衡量，后者不便衡量。
4. ddd 的核心是应对软件复杂度。
公司里业务复杂的代码其实都有类似的问题，如何降低复杂度，让软件架构合理化才是关键。
ddd 提供了一种方法论，按着这个思路走，比较容易理解。
如果强行推动 ddd，结果未必好。
因为思想不可见啊！

[ntop]

很早前和同事讨论过 DDD，我觉得奇怪的是为什么会有人觉得 DDD 是一种模式或者一个框架，DDD 那本大厚书我看完之后唯一的感觉就是这讲的是一套教你怎么分析 /设计 /维护软件的方法论，反正我是看不到任何模式和框架的。我觉得 DDD 在国内不成功的原因特别明显，DDD 强调的是在面对一个全新问题的时候你应该怎么取解决这些问题，但是我们在做开发的时候遇到的问题都是一些常规问题，这些问题都被重复解决 N 多次了，我们只要在网上搜索一下或者找人问问问题就解决了，何劳自己分析呢？所以除非是开创性的项目否则应用 DDD 这套方法论是得不偿失的。

[alcoholpad]

DDD 很棒，入职新公司后一直在用。

[janxin]

DDD 会增加系统的复杂度，增加的复杂度对很对人来说掌握难度也会上升，由于 DDD 要求统一语言，对全流程的人员（非开发）也有比较高的要求。

DDD 会增加码农工作量，没有富余人员会对项目交付进度产生额外影响。

过早优化是万恶之源。

[blless]

看想盖个摩天大楼还是小平房，反正都能住

[darrenfang]

前几年看过领域驱动设计相关的书，一直没看明白，过年期间在家里看完了《领域驱动设计精粹》，这本书有一章节讲的事件风暴，按照这个方法重构了之前的一个项目，比之前的设计方式好了很多，顺便使用上了消息服务，软件的整体设计思路还是比较清晰的。

[xiangwan]

现在市面上大部分项目都是数据驱动开发的。像 egg.js 就是典型的数据驱动思维下的架构 /文件夹划分。

说 DDD 没价值、浪费时间、互联网公司用不到、只在设计阶段有用、需要前期花很长时间完全设计好再编码，都是对 DDD 的片面认识。
DDD 是全流程全员*可*参与、受益的。前期沟通，后面的产品设计、技术设计、编码都用的上。



如果认同美团这篇博客里的观点的话，DDD 是非常值得投资的。( 领域驱动设计在互联网业务开发中的实践)[https://tech.meituan.com/2017/12/22/ddd-in-practice.html]


数据驱动开发必然导致代码不断腐化，DDD 是市面很少的成熟的解决方案。
真的复杂，真的很难落地。
不要原教旨主义。

[nl101531]

团队用不起，水平还不够

[upupddd]

不 是你没用到 或者你没碰到大佬团队

[zmxnv123]

头条商业化，在用 ddd

[xiangwan]

DDD 思维下对架构的影响可以看看 **ThoughtWorks 洞见** 的 [从三明治到六边形]( https://insights.thoughtworks.cn/from-sandwich-to-hexagon/)

[配套代码]( https://github.com/abruzzi/ddd-demo)

六边形架构的主要观点是：业务逻辑和基础实施分离。

DDD 思维对设计阶段和编码阶段的影响可以看看 **ThoughtWorks 洞见** 的 [使用 DDD 指导业务设计的一点思考] https://insights.thoughtworks.cn/ddd-business-design/

设计阶段的观点是：“停电思维“
编码阶段的主要观点是：代码要反映业务

DDD 可以减轻：
变更扩大化（ change amplification ）、认知负荷（ cognitive load ）、以及无法了解未知流程（ unknown unknowns ）-- [《软件设计的哲学》书评 ]( https://www.oschina.net/translate/notes-philosophy-software-design)

[jpmorn]

比如计费优惠券的例子，让程序员拍脑袋做一个移动公司类似的计费系统，这个领域没摸索过不懂啊

[Jooooooooo]

你上大公司就会发现还是很多的

[hantsy]

@matrix67 Eric 的 DDD 原书是一个 Spring 写的物流跟踪系统，https://github.com/citerus/dddsample-core

Java EE 6 开始移植了这个程序，使用纯 Java EE/Jakarta EE 重写，https://github.com/eclipse-ee4j/cargotracker

还有其它各种框架，模式实现（包括 Microservice ）的版本，自己搜索 Github 。

[hantsy]

DDD 是一种比较接近实战的软件开发理论，在 DesginPattern 之上，但又没有 SOLID 那么空洞。不管是企业开发，还是现在互联网的 Microservice，DDD 非常实用。特别是处理 BoundedContext，是传统 Monolithic 程序向 Microservice 迁移时，架构设计时必要分析步骤。

[Rwing]

要求团队整体水平比较高吧

[a194259440]

携程再用啊，我们公司也在用。

[hantsy]

@xiangwan 国内开发基本都是数据驱动的，所以国内还是重视写 SQL 之类的。

[hantsy]

@zclHIT 能够用 TDD 和 Pair Programming 基本都是外企和有硅谷文化的小公司。国内所谓的大厂，呵呵，真正有一些好的开发实践几乎为零（除了一两个零星的团队，也是外来的和尚建立的），吹牛逼远超国际大公司。

[momocraft]

印象里在会议看到的讲 DDD 的不少是来自开发分散的，需求模式极多的业界
比如广告竞拍

[momocraft]

至于“为什么没有 DDD 的框架”
以我的理解 DDD 不是一个语言或标准，是一套指导分析到开发的方法论

在 DDD 开发的应用可能有下级的单位 （比如规则引擎，比如 domain 的各种 util ），但很难有共通的基础。我怀疑能抽取出框架的工作可能不那么需要用 DDD 。

[hantsy]

上面提到的 Java EE/Jakrata EE 版本的 CargoTracker 文档，https://cargo-tracker.gitbook.io/documentation/ 由于 Java EE 移交到 Eclipse，所以整个 Java EE 项目地址，名字也变化了两次。

[ayavvv]

DDD 难道不火吗？？？我们这边全都是 DDD

[index90]

DDD 是方法论啊，不是什么架构模式啊，也不是什么框架啊。你连 DDD 是什么都没了解清楚，当然不知道它用在什么地方啦。LZ 自己贴的维基百科，估计自己都没认真细看吧。

[cs419]

ddd 一直都是不温不火的 大部分人应该都是摸着石头过河
帖子里说公司一直在用 ddd 的不少
不过这些 ddd 差异大吗

有点好奇这些是不是盲人摸象

[pangleon]

正经研究过一点时间 DDD 的人，因为当时做微服务遇到了拆分的问题。
后来掌握了事件风暴。
但是对 DDD 的代码级实现完全不看好。
反人类。
这东西足够好早火了，玩家都是用脚投票的，就像敏捷，吵吵这么多年了不还是这个德行，为啥？不好用啊

[hantsy]

@pangleon 跟大环境有关，不是好不好用的问题。中国公司都是急功近利，都是太过早的关注结果，而在一件事反复多少次都没一定论，造成大量时间浪费，而这些时间浪费一般公司都不会在意（加班 996 嘛 ）。上面链接有提到盒马的一篇实践文章，这文章本身我个人觉得没有什么太多价值，而且有一定的误导性，（如果出于学 DDD，应该读读下面 Thoughtworks 的链接），但其中一句描述很真实，中国公司（包括大厂）都是面条代码，一条线捅到数据库，思维上简单粗爆，根本就没有上升到真正的 Domain （就是问题本身），大部分开发都是业务出发就搞数据库，用了 OOP 语言或者框架，但架构设计和代码实现上完全脱离 OOP 原则。这样的结果是，你用了上好的食材，本来是应该一桌满汉全席，结果是出来的一锅重庆火锅。

为什么国内一些公司缺少 Domain Expert，真正从 Domain 出发思考问题，从产品角度考虑在很多公司都是执行不下去的。很多公司都是以老板看法为中心，马屁精一堆，根本就没有从业务问题出发去分析，而是看老板的喜爱。当然这是千年中国传统文化了。

[jack2020]

@charlie21 看完了，文章不错！“所有的复杂变态查询其实都应该绕过 Domain 层”很有感触。Django 框架很好的实践了 DDD

[redbelt]

看了大家的回复，结合我自己的感受，结论是：DDD 乃真屠龙宝刀也！

[pangleon]

@hantsy 来来来一起说道说道这个，当时看 DDD 的时候也是搜到河马，美团有在用，可是那个文章写的，隔靴搔痒一般好不痛快。我们代码层级多少人习惯了贫血模型你让他改，他所有的代码你都得 REVIEW，累都累死，再一个万物皆事件这个事产品经理也不干啊，很多场景就是要个实时反馈。
现在 DDD 的门槛在这，哪个 LEADER 敢打包票我花一段时间带团队学能搞定搞定后为公司做贡献。不是人人都想搞这些，人家想的都是微服务好出去面试。
这就相当于国足的青训做的不好，你还怎么指望出人才？出成果？
领域专家这个更蛋疼，这年头都 35 岁裁员了，还专个毛啊，有个笑话就是华为海外项目经理大都是年轻人，靠能拼打天下，结果一看其他外国公司都是上了年纪的，大形势如此。
敏捷这玩意就是反人类在觉得团队各个都是人才，说话有好听，做事又靠谱。
都是虚的，取其精华而不能全都拿来就用，东施效颦。

[charlie21]

@pangleon 更常见的说法是 “庙小盛不下大佛”，大佛就是 DDD

[kyuuseiryuu]

Deadline-Driven Develop [ok]

[lewis89]

@exploreXin #40 我再补充一句，以国内低廉的劳动力成本远达不到需要使用更高层次的开发流程来应对复杂度的问题，国内应对软件复杂度的方法通常就是堆人堆工时，反正码农价格便宜，从资本的角度来看，有廉价的人可以使用，完全没有提升生产效率的动力。

[lewis89]

@hantsy #75 说白就是成本问题，如果你有大批能够 996 又愿意吃苦耐劳，能在屎山里面 debug 的低价程序员可以用？何必去使用更高层次的开发方法论来管控软件复杂度？ 就像工厂里面有大量廉价的人工使用成本远低于自动化设备，而且可以召之即来挥之即去，又没有工会替他们争取基本福利跟劳工保障，你觉得资本家还有必要去使用自动化设备吗？

[DoodleSit]

Diss Developer Department!

- 来自 Product 团队