DDD 为什么火不起来？

[Hanggi]

DDD 贴链接：维基百科

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

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

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

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

[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 要看软件对应的问题是否复杂到一般方法无法解决的程度，而不是想要用一个新技术尝尝鲜而强行推广，那样的话，就是扔掉苍蝇拍，搬出大炮来打蚊子了，大炮固然厉害，但是无法完成消灭蚊子的问题。