DDD 从入门到放弃

[zzNaLOGIC]

2024 年了我终于放弃琢磨这玩意，几番尝试之后最终还是认清了现实。
理论虽好但不是包治百病，虽然能解决潜在问题，但前期投入无法令老板接受。
DDD 之难不在技术，而在于人。
仅通用语言和边界定义就足够让 DDD 绝了在绝大部分公司推行的路。
1.驱动设计？
老板：我们也要跟上时代，全面推行 DDD
冤种们：好好好！
老板：时间紧任务重，下周就上线有没有信心？先上线再迭代！
冤种们：………
2.领域拆分？
领域业务专家： 我们有这玩意么？好像没有…那个谁，我认命你为领域业务专家，工资不变给你加个 title ，从此你就负责这个了。
冤种们：………
（第二天）
冤种们：专家我们来拆分定义下业务边界吧
“专家”：边界？我们的业务就是随客户需求不断进化，提升的！不要随便给自己定边界，那是限制自己的视野，我们的边界就是客户无边界，服务无边界！
冤种们：………
3.内部推行？
冤种 1:各位，目前我们先在这个子业务上尝试下 DDD 的模式，希望大家在这个模块上严格遵守边界规则，我们实行一段时间。
萌新 1:边界是啥？我这个需求好麻烦，看我一把梭哈。
萌新 2:好麻烦，这简直就是在降低我的效率，也是在降低公司的效率。这老梆子是不是折腾我们跟老板显绩效呢？我要跟老板反馈。整顿职场！
油条 1:麻烦，一把梭
油条 2:麻烦，一把梭
（一周后）
老板：实行已经一周了，我没有看到明显的优势在哪里，反而不少人反馈影响效率。还有不少业务部门反映跟客户变更服务受限制了，这和我们以用户为中心的文化不符，这个东西你不要搞了。
冤种：……… 老…老板英明。这就取消

[Glauben]

作为一个被忽悠着研究 DDD 一两个月的，我的评价是这玩意儿就是拿一堆高大上的词汇忽悠老板的。

可能最开始实行的公司符合他们的业务吧，在我研究了一段日子后，这玩意儿离银弹差了十万八千里，请教过一些所谓的 DDD 大佬，遇到他们业务之外的东西，他们也不知道怎么写才好。

在不同的公司 DDD 的理论都不一样，根本没有一套通用的架构。想要把自己的业务生搬硬套在那些个大厂宣传的 DDD 中简直是地狱，回头是岸。

[horizon]

@Glauben #1
"所谓的 DDD 大佬，遇到他们业务之外的东西，他们也不知道怎么写才好"
这是真正的 DDD

[RedBeanIce]

我司是个小公司，我司在推行 DDD ，主动推进的人之前也在另外一个公司推行 DDD

每个公司落地 DDD 都不一样，我司技术栈很奇怪，所以落地的也很奇怪。
但是确实是朝着 DDD 的目标进发。

[sky3hao]

说明你压根没有入门, 也可能你环境不利于你入门.

真正掌握了 DDD, 其实你不会想回去走老路的

[zzNaLOGIC]

@sky3hao 可能确实字太长不想看
仔细看完我的经历你就能明白为什么放弃了
重点不在于想不想走老路，而在于（）。。。。

[zzNaLOGIC]

@sky3hao 这玩意的重点根本就不在于某个人/某部分人有没有掌握/深入/精通
“DDD 之难不在技术，而在于人。”

[sky3hao]

即使你跟一个不懂 DDD 的产品沟通任何非 DDD 的设计, 你也可以写出 DDD 的代码来. 难还是技术

[BeautifulSoap]

不是所有人都赞同推广的时候，要推 DDD 就别说自己是在用 DDD ，而是潜移默化地推。
通用语言，领域专家、边界这东西，不去专门了解谁知道是啥，大家也不会乐意跟你多学这些东西

如果你是管项目的话，直接跟客户还有组员说，因为开发团队和客户之间经常关于名词有不一样地认识导致开发出错，所以我想统一一下名词，我这里根据客户地叫法整理了一个“名词表”，你们看看有没有意见，今后就按照这个名词来推进项目。组内有人用错名词的话就主动纠正他让他用正确的叫法。至于客户那边，如果你没法改变客户的叫法那通用语言就完全按照客户叫法来调整
至于领域专家，直接就跟客户说我需要你们那提供一两个能和我门对接，解答我们疑问的熟悉业务的人，只字别提什么“领域专家”
至于拆领域，找核心领域，子领域之类的，边界之类的的名词更是只字别提，直接就让客户给你讲讲业务范围，业务内容，然后你把业务问详细了，自己画几个图，美其名曰“业务构成图”，下次会议把疑问和图给客户看看有问题就提，没问题的话留下证据，顺便今后扯皮时还能甩锅给客户

这一套下来你就会发现，DDD 其实也没那么操蛋，当然这一套下来这叫不叫 DDD 是个问题了

[zzNaLOGIC]

@BeautifulSoap 实操下来确实会发现，这套东西确实太理想化了。这玩意想搞下来对业务部门与技术部门沟通、业务部门人员本身素质要求还是比较高的（有部分业务部门其实本身也是浑浑噩噩的，没有流程没有标准，但由于不像技术部门后果呈现这么明显，一般也就非标特殊化处理完就过去了，在这种情况下部门业务想确定边界根本是无稽之谈，更别提后续的架构设计了）从上到下遇到的问题综合起来，技术反而是最简单的，因为可确定、可量化、标准易定。
你说的方法确实是后期实操的方案，这也是逼不得已。目前的落地情况，已经不是怪异可以形容的了。当然怪不怪异不重要，重要的是能解决问题，但实际上。。。变异后的情况已经有些偏离设想的道路了。哎，也不知道是福是祸

[Mithril]

@BeautifulSoap 同意。叫不叫 DDD 无所谓，只要比现在一锅粥的架构强，那就有实践的价值。

很多东西完全按理论走结果肯定是最好的，但成本也不一定是所有人都能接受的。包括开发成本，人员的培训成本，PM 和客户的额外沟通成本等。

比如 Restful 设计，很少会完全按照它来设计 API 。但它的思想是好的，借用到项目里能有改善，那就值得去学习和尝试。

[NoNewWorld]

DDD 的一些编程思想还行，完全推太难了，而且没必要，没有银弹，DDD 也不会是银弹。

[jamosLi]

有没有可能任何事都是“开干”而不是“开会”？
任何一个公司都基本不存在重构一说。能从基础开搞就从基础开搞，不能就是敏捷套 DDD 的搞，一顿乱喷的只能说是你自己本身无能。

[zzNaLOGIC]

@jamosLi 谢谢
但其实以上言论
均处于实操—>落地（成功 or 失败 or 流产）—>总结 的第三个阶段

[u4zada]

我们已经落地 DDD 两年了，有做的好的工程，也有做的不好的。你不能光把 DDD 的概念往项目上生搬硬套，否则很容易跑偏

[zzNaLOGIC]

@u4zada 没有否定该思维的意思
我只想说太挑团队了
也确实是我能力有限
我已经放弃了

[unregister]

感觉.net 以前有很多 d d d 相关的

[troywinter]

当你的业务足够复杂以后，你会发现 ddd 的一些优势，当七八年以后你再回过头来看你现在想法，也许会有不同的认识，当然在国内系统不考虑任何可维护性可迭代性的情况下，完全靠堆人解决问题，也许确实不需要 ddd

[GoflyYang]

我写了一个星期 DDD 被太多名词困扰 简直没有耐心看了

[jonsmith]

之前大略看了 DDD 书籍的目录，庞大且复杂，还没来得及专研。技术架构要与公司相匹配，硬推估计不行。

[xuyankang]

DDD 还是相当有价值的，要实践好不容易，对人要求很高。
我对 DDD 的理解，其本质就是充血模型的编程，核心在各个概念的抽象。概念抽象好了后，自然边界就出来了。不要拘泥于各种 XO 的转换，不要拘泥于教科书的分层，关键点在于要理清你的逻辑是“依赖什么的”，如果 A 依赖 B ，那么 A 其实不是独立存在，B 的东西直接用就行，没必要再搞个防腐层。
另外，DDD 一般架构师搞搞就行了。我一般都是把所有核心的类和方法设计好之后，然后让大家在“框里”写代码就好了。

[abz]

从业务到模块到类，一个原则，高内聚低耦合，单向依赖，这是大原则，至于怎么实现，每个人有每个人的途径！做好以上，都叫 ddd 。

[abz]

单向依赖说一下，无论在域层面，模块层面，还是所谓的 ddd 分层层面，都要注意这个原则。至于战术层面，所谓聚合根就是高内聚的一种表现。ddd 的初衷是为了持续性的维护，它必然遵守高内聚低耦合这一最本质的原则。所谓的分层所谓的依赖倒置，单向依赖而已，这两个本质贯穿始终。仓库也是一样，不必纠结 save 还是 update.哪个习惯用哪个，只要和领域层不耦合在一起，保持领域层的稳定性就行。

[abz]

我这么一说，其实就很简单了。

[abz]

ddd 无所谓项目简单与复杂，只不过复杂的项目即便你不用 ddd 一样也很复杂，简单的项目简简单单实现就好。关键你要知道怎么用 ddd ，就是高内聚低耦合，单向依赖。再加个业务专家，一切水到渠成。即便没有业务专家，按照这个原则实现出来的项目也不会差。