DDD 领域模型的好处到底是什么

[mitsuizzz]

网上说法千奇百怪，DDD 分层导致实体转来转去，标准是什么，好处到底是什么

[lostSoul]

可以唬住领导

[AlkTTT]

DDD 开篇就说了，要团队内的成员对整个系统的认知要全知全能，业务术语是一致的；
光这点国内大部分团队都做不到，所以 DDD 对大部分团队是没啥用的，反而会增加代码复杂性，不好接盘；

[zhujq]

@lostSoul +1

[ryougifujino]

好处之一是可以避免事务脚本，把业务逻辑以面向对象的形式进行抽象，增强复用性、可测试性。

[timethinker]

一种方法论，DDD 的作者根据自己的经验提炼得出的一套通用建模方法，分为战术模式（ tactical patterns ）和战略模式（ strategic patterns ），其中战略模式是比较难以理解和抽象的，同时也是最重要。战术模式则可以归结为类似设计模式一样的方法工具。

难以理解就意味着用的人少，不好推广，可能一些团队的 leader 会强推或者应用其中的一部分，我想说的是放弃它是非常容易的，不对其进行维护就行了，但是重新拾取起来就会非常困难了。就像 TDD 一样，在思维没有转变过来之前，很多人就会认为它是浪费时间浪费成本的开发模式。

破窗效应所引发的一个结果就是，如果团队中有一个人可以打破规则，并且不受约束和惩罚，那么其他人也会尝试挑战规则，最终的结果就是混乱。

[shijieheping]

@lostSoul #1 哈哈

[easylee]

DDD 目前在国内“百花齐放”，各种魔改和瞎写，用得极其辣眼睛。
某某大厂中就是如 @lostSoul #1 所说的，为了 KPI 和技术分享好听。

[baiyi]

DDD 的副标题就是：软件核心复杂性应对之道。很多时候软件的复杂性不在于软件技术的使用，而是业务的复杂性，所以 DDD 就聚焦于业务逻辑，通过各种方法来为业务建模，来保证不会因为业务的巨大复杂性而陷入困境。
我一直认为我没学会 DDD 的原因之一就是还没遇到过于复杂的业务逻辑......

[buzailianxi]

唬住领导

[Umenezumi]

要么全会 DDD，要么全不了解 DDD，不然写出的代码有你受的

[charlie21]

一个更好的问题是，就项目负责人而言（他决定是否采用 DDD ）
为什么有的人觉得 DDD 的收益大于成本，为什么有的人觉得 DDD 成本大于收益，依据是什么

[e583409]

DDD 对于有追求的程序员 还是要学学的

[afewok]

可以提取一些精华，比如从业务的视角，可以促进产研一起明确业务的核心

[passerbytiny]

没好处。非但 DDD 没好处，基本上本世纪甚至上世纪 90 年代以来新出的大多数软件领域名词，例如敏捷开发、scrum，都没好处——因为它们压根就不是工程技术或者方法，只不过是技术大牛或大厂的经验分享。

[dany813]

前提对业务很了解才能，DDD

[BeautifulSoap]

读过 Eric Evans 的那本领域驱动设计就知道，DDD 的核心不在于分层或者具体的代码实现，而在于整个团队在领域专家的协助下，学习领域知识统一通用语言，共用一个领域模型。这不光要求团队所有成员交流都基于统一的领域模型和通用语言，还要求你的客户（毕竟领域专家基本就来源你的客户）也和你用同一套模型和语言。实际上你想想，如果一个项目能做到上面这些要求，你的项目本来就能减少非常大难度

之后的分层之类的其实都只是为了在代码上实现更好领域模型的具体方法，而不是 DDD 的核心。可问题在于拜 Eric Evans 那本 DDD 写得实在是过于“高屋建瓴”所致，关于 DDD 到底怎么落地都一直都是个让人头疼的问题。所以才出现了各种各样的不一样的实现方法。也就是所说的用来唬住领导

[ZRS]

业务要足够复杂 且有领域专家 DDD 才有用武之地

[JamesChen]

@mitsuizzz 单纯好奇，问个题外话，为什么要拿 Hiberbee 的 logo 做头像？（我项目的 logo 就是找人参考 Hiberbee 画的，哈哈哈）

[FreeEx]

以前是黑猫白猫能抓住老鼠就是好猫，后来有个人说黑猫白猫都不好，能抓老鼠但是把家里弄得一团糟，我们需要分析老鼠的目的，找出老鼠的活动轨迹，划定每一只老鼠的领地，在指定的地方放上猫等老鼠过来，这样既可以抓老鼠，又不会搞乱房间。但是老鼠不听话呀，不按照既定路线走，于是就各种研究怎么样才能按照这种方式抓住老鼠。

[mitsuizzz]

@JamesChen 因为可爱 我 idea 的主题就是用的 Hiberbee