这是一个创建于 1621 天前的主题，其中的信息可能已经有所发展或是发生改变。
网上说法千奇百怪，DDD 分层导致实体转来转去，标准是什么，好处到底是什么
 | 1 lostSoul 2021-05-07 09:08:30 +08:00 可以唬住领导 |
 | 2 AlkTTT 2021-05-07 09:11:17 +08:00  1 DDD 开篇就说了，要团队内的成员对整个系统的认知要全知全能，业务术语是一致的； 光这点国内大部分团队都做不到，所以 DDD 对大部分团队是没啥用的，反而会增加代码复杂性，不好接盘； |
 | 4 ryougifujino 2021-05-07 09:19:39 +08:00 好处之一是可以避免事务脚本，把业务逻辑以面向对象的形式进行抽象，增强复用性、可测试性。 |
 | 5 timethinker 2021-05-07 09:35:57 +08:00 2 一种方法论，DDD 的作者根据自己的经验提炼得出的一套通用建模方法，分为战术模式（ tactical patterns ）和战略模式（ strategic patterns ），其中战略模式是比较难以理解和抽象的，同时也是最重要。战术模式则可以归结为类似设计模式一样的方法工具。 难以理解就意味着用的人少，不好推广，可能一些团队的 leader 会强推或者应用其中的一部分，我想说的是放弃它是非常容易的，不对其进行维护就行了，但是重新拾取起来就会非常困难了。就像 TDD 一样，在思维没有转变过来之前，很多人就会认为它是浪费时间浪费成本的开发模式。 破窗效应所引发的一个结果就是，如果团队中有一个人可以打破规则，并且不受约束和惩罚，那么其他人也会尝试挑战规则，最终的结果就是混乱。 |
 | 6 shijieheping 2021-05-07 09:49:44 +08:00 @lostSoul #1 哈哈 |
 | 7 easylee 2021-05-07 09:52:56 +08:00 DDD 目前在国内“百花齐放”，各种魔改和瞎写，用得极其辣眼睛。 某某大厂中就是如 @lostSoul #1 所说的，为了KPI 和技术分享好听。 |
 | 8 baiyi 2021-05-07 09:55:19 +08:00 2 DDD 的副标题就是：软件核心复杂性应对之道。很多时候软件的复杂性不在于软件技术的使用，而是业务的复杂性，所以 DDD 就聚焦于业务逻辑，通过各种方法来为业务建模，来保证不会因为业务的巨大复杂性而陷入困境。 我一直认为我没学会 DDD 的原因之一就是还没遇到过于复杂的业务逻辑...... |
 | 9 buzailianxi 2021-05-07 09:55:30 +08:00 唬住领导 |
 | 10 Umenezumi 2021-05-07 10:01:18 +08:00 要么全会 DDD，要么全不了解 DDD，不然写出的代码有你受的 |
 | 11 charlie21 2021-05-07 10:36:35 +08:00 一个更好的问题是，就项目负责人而言（他决定是否采用 DDD ） 为什么有的人觉得 DDD 的收益大于成本，为什么有的人觉得 DDD 成本大于收益，依据是什么 |
 | 12 e583409 2021-05-07 11:27:44 +08:00 DDD 对于有追求的程序员 还是要学学的 |
 | 13 afewok 2021-05-07 11:36:40 +08:00 可以提取一些精华，比如从业务的视角，可以促进产研一起明确业务的核心 |
 | 14 passerbytiny 2021-05-07 11:47:48 +08:00 via Android 2 没好处。非但 DDD 没好处，基本上本世纪甚至上世纪 90 年代以来新出的大多数软件领域名词，例如敏捷开发、scrum，都没好处因为它们压根就不是工程技术或者方法，只不过是技术大牛或大厂的经验分享。 |
 | 15 dany813 2021-05-07 12:05:14 +08:00 前提对业务很了解才能，DDD |
 | 16 BeautifulSoap 2021-05-07 12:37:48 +08:00 3 读过 Eric Evans 的那本领域驱动设计就知道，DDD 的核心不在于分层或者具体的代码实现，而在于整个团队在领域专家的协助下，学习领域知识统一通用语言，共用一个领域模型。这不光要求团队所有成员交流都基于统一的领域模型和通用语言，还要求你的客户（毕竟领域专家基本就来源你的客户）也和你用同一套模型和语言。实际上你想想，如果一个项目能做到上面这些要求，你的项目本来就能减少非常大难度 之后的分层之类的其实都只是为了在代码上实现更好领域模型的具体方法，而不是 DDD 的核心。可问题在于拜 Eric Evans 那本 DDD 写得实在是过于“高屋建瓴”所致，关于 DDD 到底怎么落地都一直都是个让人头疼的问题。所以才出现了各种各样的不一样的实现方法。也就是所说的用来唬住领导 |
 | 17 ZRS 2021-05-07 12:45:16 +08:00 via iPhone 业务要足够复杂 且有领域专家 DDD 才有用武之地 |
 | 18 JamesChen 2021-05-07 12:57:22 +08:00 @mitsuizzz 单纯好奇，问个题外话，为什么要拿 Hiberbee 的 logo 做头像？（我项目的 logo 就是找人参考 Hiberbee 画的，哈哈哈） |
 | 19 FreeEx 2021-05-07 13:02:32 +08:00 以前是黑猫白猫能抓住老鼠就是好猫，后来有个人说黑猫白猫都不好，能抓老鼠但是把家里弄得一团糟，我们需要分析老鼠的目的，找出老鼠的活动轨迹，划定每一只老鼠的领地，在指定的地方放上猫等老鼠过来，这样既可以抓老鼠，又不会搞乱房间。但是老鼠不听话呀，不按照既定路线走，于是就各种研究怎么样才能按照这种方式抓住老鼠。 |
 | 21 cys02688 2021-05-07 15:21:36 +08:00 ddd 实践其实真的要看公司，得真的有那个环境，最主要的是要让产品和需求习惯这种方式。他们要是习惯了，基本就很好搞了 |
 | 22 lachesis 2021-05-07 15:56:49 +08:00 分层？ DDD 不都是六边形架构吗，将所有打平依赖于抽象不再区分高低层。 如果你说的是不同领域或限界上下文之间的实体聚合转换，然后又觉得明明是同一个东西转来转去，那大概就是上面有人说的战略设计出了问题，上下文没划分好。 |
 | 24 cs419 2021-05-08 08:13:34 +08:00 爱情就像鬼 相信的人多 见过的人少 DDD 也这样 张三说他的项目是基于 DDD 做的 也没觉着很强大 李四说 那是因为你水平不行 真正的 DDD 很牛掰的 网上有不少博文写 DDD 你看不懂，也不好说人家写的不对 场面是充了，没人能说清楚牛在哪 感觉 DDD 就像数学界的 xxx 设想 你一个泡泡 我一个泡泡 没一个能打的 |
 | 25 bthulu 2021-05-08 08:46:21 +08:00 DDD 就是垃圾中的垃圾, 不服上 github 源码给大伙瞧瞧 |
 | 26 zhognan 2021-05-14 11:10:45 +08:00 DDD 说白了就是一些人吹牛一种理论，如果没有微服务，有可能现在都没有提起，微服务才是一种最佳落地实践，我觉得是微服务拯救了 DDD |
 | 27 RandomJoke 2021-05-19 16:50:16 +08:00 DDD 没有代码上的标准吧，也就思想上的标准，好处就是当系统复杂到一定程度，大家有一套统一的术语理解和沟通，降低复杂系统后续的维护和拓展成本 |
 | 28 chenyang 2021-05-24 00:42:11 +08:00 更容易写到沟里去 |
Select Language