关于 DDD 的感想

[liliumss]

看多了各种丑陋的代码后，觉得 DDD 真是好东西 但是又觉得没什么卵用

代码写的在好，也要接搜别人恶心的代码，改造起来非常困难，大部分单位工时也不给你这个时间去设计领域模型， 大家在工作中是怎么做的呢

[sagaxu]

就算完全不提 ddd 的公司，拿到一个新项目的时候，也会有详细的需求分析，明确好几个阶段的产品规划。然后技术人员吃透业务，再开始做整体业务架构设计，然后再做整体技术设计，之后便分模块梳理主要接口和细化技术细节。

在这个过程之后，才是撸起袖子写代码。而 ddd 的力度更细，连一个小功能内部都要一二三四五，几十行代码的功能能给你整几十个文件出来，各种未来变化都给你隔离开来。

个人以为 ddd 不太适合快速演化，我在实践中更倾向于通过持续重构适应业务，不断迭代，从结果上无限趋向于 ddd 。

[xuanbg]

@cheng6563 不给设计时间的 boss 不踹掉还要留着过年吗？

[asanelder]

@sagaxu #21 俺遇到的都是给你 3 天让你设计不错了，然后一个星期要求搞定。。。

最终就是从数据库一直穿到 controller，各种查出数据后对字段的操作。

[encro]

当前框架 spring, laravel, symfony 等 就是 DDD 思想的具体执行吧。

[tesguest123]

@asanelder 一样，基本上都要求快速出活，想设计？加班设计吧！

[cloudhuang]

DDD 被过度神话了，特别是自媒体之后，嘴上没个把门的。DDD 并不能解决各种丑陋的代码，因为 DDD 的输出，其实并不是直接的代码。

> 大部分单位工时也不给你这个时间去设计领域模型
相反的，其实各个公司这部分的时间，真没有省，一个新项目下来，各种需求分析，各种项目规划，评审，业务分析师，系统架构师，都是要弄清需求，吃透业务。

DDD 上的几个概念，我觉得单根性的作用很大（尽管项目大了之后，问题也很明显），其他的，什么限界上下文，什么 context map，都不是一成不变的。

代码写的烂，就补代码，不是引入 DDD 就能解决的。

[wangxin13g]

DDD 的问题从来不在于 DDD 行不行 而在于人行不行

[pjntt]

写 DDD 的人,上过 996 么?

[mightofcode]

DDD 不能帮你晋升
不能帮你跳槽

[elintwenty]

对业务足够了解才可以 DDD，而且还要看工期、人员配置等多方面的因素。在快速迭代 /试错 /摸索的、不能确切明确业务核心的情况下，谈 DDD 完全是徒劳；如果深入了解了业务，不需要所谓的 DDD 自己也可以抓住 DDD 的核心去实践。
本质上 DDD 是业务项目的应用 OOP 的设计与指导思想，锦上添花之用，不是银弹，更和代码质量没什么直接关系。如果仅仅为了 DDD 而 DDD，必然南辕北辙。

[idoggy]

能把设计做好就谢谢各位乡亲父老了，ddd 还得靠后站。
现在很多 bug 都是开发不认真写设计方案导致的，认真写了设计方案，很多 ddd 里提到的东西都会在设计中体现的，比如统一术语，边界隔离，防腐层等等。也就聚合根这个概念是要花精力去弄，但是架不住需求变动更快，设计聚合根会感觉对不起自己的产出。
想玩 ddd，先把 tdd 整好再说，能有多少团队真的能坚持把测试代码一直维护下去不然它衰败的。

[alonehat]

微服务、中台、DDD 这类所谓新概念真的新吗？实际做过几年项目应该都知道项目结构里几种分层方法，用的多了抽出来公共的部分单独引用叫 common，这样的公共部分不限于具体功能的时候就叫 DDD ；许多提供结果集的方法轻易不会改动但很多地方用，抽出来做个服务就叫中台；单体应用并发数高了撑不住了就多部署几个，为了配置方便弄个所谓配置中心、服务发现注册中心、有重试的快速报错叫熔断和服务降级，合起来就是微服务，等等等等不胜枚举，说到底没什么新东西，时间长点就发现其实都是换几个工具的问题，什么 DDD 都是浮云，好好分自己的层，抽自己的公共部分比什么都强

[liliumss]

看了各位的回复，感觉果然 ddd 不好落地啊

[cys02688]

小白一枚，一直在找 DDD 实践。个人的理解其实 DDD 是业务和技术寻求通用语言的一种方式，这里面隐含一个前提，就是业务人员对业务的认识必须是立体化和结构化的，从横向上讲，业务人员必须对各种业务概率之间的联系非常清晰，从纵向讲，业务人员必须对未来业务演进有个大致方向。如果业务人员对业务的横向认识都不足够，那就别奢求用 ddd 了。如果是以短平快的项目交付为主，那就按短平快的项目交付来，每个项目都是独立的代码，别奢求抽取通用逻辑。如果产品和销售部门是短期结果导向而技术部门却想着产品化的长期思考，这种严重的部门间逻辑对立必然导致业务和技术两个部门都非常混乱。这些也是大家要考虑好的

[putaozhenhaochi]

@xuanbg 接楼问下，关于设计用 UML 吗？能否指导下关键流程及工具

[xuanbg]

@putaozhenhaochi 我用思维导图描述整个应用的功能结构来替代 UML 。所以，UML 不是关键，也不是唯一的设计语言。习惯 UML 的，当然可以继续用，不习惯的，也没必要强上。对于复杂流程，还是需要画流程图的。个人建议使用 BPMN 流程来描述，表述能力更强。