DDD 为什么火不起来？

[Hanggi]

DDD 贴链接：维基百科

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

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

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

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]

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