关于 DDD 的感想

这东西这些年一直不温不火的，虽然近几个微服务体系下又获新生，可面对一众习惯了面向对象的开发人员，想统一对领域的理解太难了，领域边界每个人都有自己的认识，在一个需求里，划分边界本身就是个问题，而且开发方式的转变更是加大了推广难度，反正我们试过，最后没坚持下来

算是一个指导思想吧。 最后能不能统一你们公司的代码风格就看你们 code review 的严格程度了。任何好的制度、不强制执行都是不行的。

能不能成关键在团队素质，如果整体水平相差不大的话，DDD 还是比较好落地

当然要花时间好好做设计了，所谓磨刀不误砍柴工，怎么都 2020 年了还有人不懂。有人觉得没有时间去做设计，这个大概率是设计做得不够好，没有起到应有的效果。对于这种情况，我只能说“坚持下去”！任何能力的锻炼都是需要时间的，不积跬步无以至千里。

举一个最新的栗子吧。我月初接了个活，app/商户 /平台 3 端，这个系统有 3 大模块 20 张表 80 多个接口，要和 Javashop 集成。我要负责开发环境的部署和服务端代码的编写。只要是服务端的都归我。。。甲方要求 20 号交付，我还提前了几天，总计大概花了 120 个工时吧。其中折腾开发环境就足足 1 周的时间，占了总工时的 1/3 ！！！为啥呢？因为甲方没有文档，全靠猜。然后设计有个 10 来天吧，中间和甲方来回沟通落实细节。甲方的原型漏洞百出，没办法，只能多花时间沟通落实。真正写代码的时间有多少？ 3 天都不到！只占总工时的 1/5 。

所以呢，在设计上多投入，是非常划算的事情。

DDD 是什么?

@sagaxu 大多是增删改查的八股代码，复制-粘贴-稍微改改。平均下来十几分钟一个接口，也不算快。

产品经理只说一句：今晚就要，明天上线！

@RRRoger 领域驱动设计

@xuanbg #4
@sagaxu #6

以俺的经历来说，其实设计的好，真正写代码时，是不怎么需要动脑的。

前提是自己设计的好。

还面临一众读不懂 ddd 瞎吓唬 ddd 的人，比如一楼。

DDD 就是扯淡

不好落地

V 站的柠檬精真不是一般的多。

成为那个有话语权的人就好了

设计是核心

写不动也不想写 写了段时间放弃了 没有专业领域能做决定的人 很难

soa 思想不到位的话，ddd 做起来就比较难受。

@xuanbg 可是 BOSS 可不会给你时间磨刀

其实感觉更是 kpi 的产物，并不是所有公司需要所谓的 DDD 微服务

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

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

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

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

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

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

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

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

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

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

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

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

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

写 DDD 的人,上过 996 么?

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

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

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

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

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

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

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

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