DDD 到底啥，有啥用

[frank1256]

rt

求大佬给我指点指点。

https://i.imgur.com/IJRFbi4.png)

[zzfer]

我最近也在学，在看《领域驱动设计》。感觉就像是一种设计模式，也没看明白，等大佬指点。

楼主你这文档能分享吗？

[frank1256]

@zzfer 这我自己写的疑问，不是文档

[BenX]

最近也在看

推荐作者 欧创新的书和极客时间上的课程
《中台架构与实现》基于 DDD 和微服务
极客时间课程搜作者。

[sadfQED2]

忽悠领导，面试忽悠薪资，晋升吹牛逼，就这几个用处

[timethinker]

总的来说，DDD 分为两个部分，一个是技术实践的战术模式，一个是工程架构的战略模式。

其中，战术模式仅作为实现的部分参考，总结的是以面向对象范式编程语言的一些常用技巧与原则，提炼出了一些可以跟非技术人员沟通的构建单元，也就是你可以跟产品直接聊的一些东西，比如实体、值对象、仓库等等。

其实最重要的是战略模式，这部分也是大多数接触 DDD 的人觉得云雾缭绕的东西，看不见摸不着。团队规模小了，搞这些觉得繁琐，团队规模大了，面对已经成熟的 CRUD 基本上都有一套成熟的流程方案了。所以这个东西真正有价值的还是回归本质，解决软件核心中的复杂性。

首先你得是一个团队，否则的话一个人还搞什么 DDD 对吧？其次对团队里面的人也要有一定的要求，起码在沟通上，要明确价值。也就是说哪些信息对于不同岗位的人来说是明确的，是可以沟通的和达成共识的，哪些信息对开发或者产品来说就是废话，要把能够体现出真正用意的这部分提炼出来，在整个团队中进行传播和理解。

其次，有了高效的沟通和统一的理解以后，才能对同一个事物进行拓展（研发），需要在前者的基础之上，搭建一套能够迅速有效解决问题的工作流程，对产品进行高效的迭代。DDD 的战略部分就是基于前者，然后再结合一些准则和经验，帮助你如何解决更大规模的软件工程问题。

以上这些当然都是很美好的初衷，但是我个人认为，关键变量不在于每次迭代能否更进一步，而在于对人的管理，什么意思呢？人的不确定性才是最大的不确定性，人这个变量的影响范围如果能够控制住，培训也好，工作范围的划分也好，只要能够达到一种“柔性”的状态，终归会回归正轨。

说得有点多了，尽信书，不如无书，要有自己的思考。

[shyrock]

DDD 的核心就是统一业务和研发的理解，实现一个模型贯穿业务和技术。
是非常理想的建模和开发过程，不过对于业务分析师、架构师和开发人员的要求太高了，很难落地。

[debuggerx]

@sadfQED2 人间清醒

[timethinker]

如果我们的眼光只局限在技术层面，那么 DDD 对你而言有用的就是战术模式那一部分，也就是编码的那一部分。如果我们把眼光放高一些，着手解决整个产品研发生命周期的效率方面，或者 DDD 就能帮大忙。这不仅仅使我们工作更加轻松，更加快乐，也使得我们不会把时间浪费在一些经常反复出现并且很愚蠢的事情上面。当然这个愿望很美好，但是不一定每个人都想做得这么美好。

[w4n9hu1]

一种设计思想，domain driven ，和 restful 相似，是一种面向业务对象的抽象，相比面向过程，复用率更高，容易应对复杂业务需求变动。

[WalkerCeng]

dddd 懂得都懂

[murmur]

DDD 软考高级是不是考点啊

[debuggerx]

不要只想着是不是用 DDD 就真能解决技术问题和项目设计问题，眼界放开阔一点，就像 L4 说的，有没有一种可能，这玩意儿的意义本来就是给某些所谓的技术人提供一条非技术的晋升通道～

[yolio2003]

还是有点用的，只是难落地。话说如果紧靠吹嘘能让大家都认可，似乎也是个很牛的本事。

[testFor]

最近在看没看懂,感觉原理是上策,实现是下策,两本看完才有感悟

[thinkershare]

回到面向对象最初的初衷, 而不是将面向对象写成流程处理模式的事务脚本.
如果你的业务 CURD 能 hold 住用 CURD 的事务脚本模式也没啥问题!
DDD 需要较高的成本, 而且再没有任何基础设施的情况下, 很容易写偏.
不过它的战略模式还是很有用的, 对大部分项目都有一定的参考价值.
我们使用 DDD 写过几个项目了, 框架使用的是 ABP, 团队也在自己重现构建内部 DDD 框架.
主要是团队的人都习惯了强事务一致性的事务脚本, 将多个模型的操作糅合到一个 Service, 导致 Service 变成了大杂烩, 越来越难以维护, 最终不得不研究使用 DDD 做切分, 后来又不得不上 CQRS, 前期阻力比较大, 现在再稳定维护期后, 大家就很爽, 添加功能也变得比原来容易多了.

[thinkershare]

@frank1256 可以多多交流, 我现在按照 DDD 这套写了也快 5 年了, 蒙蔽的地方还是很多, 但目前刚好能 HOLD 住现在的项目的复杂度. 如果你的项目不是长期维护, 使用 DDD 写是不值得的.

[aragakiyuii]

我看了 DDD 才知道怎么写 OOP😂

[coolair]

DDD 这东西并不是最近几年才出来的东西，早在 04 年就有了，只不过现在某些人接着“微服务”这阵风开始炒作了。

国内的 IT 现状目前就是这样，中台火的时候，铺天盖地都是中台，是个公司就要搞中台，好像不搞中台就不是搞 IT 的了，到头来很多公司花了大力气却什么也没做出来，或者做了个创造不了收益的东西出来。

AI 火的时候，到处是 Python ，当然是 Python ，毕竟正儿八经的 AI 还是要点门槛的，那些个鼓吹者就退而求其次，选了 Python 这个标的，培训班如雨后春笋般拔地而起，似乎每个人都得学会 Python ，包括前台文员、幼儿园孩子，好像不会 Python 就啥也干不成似的。

接着就是低代码，那些个平台写的都是写啥玩意，说是产品不像产品，说是工具不像工具。目标定位是抢程序员的饭碗，还是抢 Excel 的饭碗？搞来搞去又是浪费精力整了一堆垃圾。

然后就是 K8S 、Go ，又是铺天盖地的广告、宣传，仿佛大厂招人就以这个为界定，年入几十万不是梦。正儿八经招聘网站一搜，还是 Java 的天下。

在国内，大多数公司，什么设计模式、理念、原理、算法都是扯淡，最后还是八股文走天下，晋升考的是嘴巴和 PPT ，其他都是浮云。

[drackzy]

方法论、敏捷那一套，换个写法。

[frank1256]

@thinkershare 我的 leader 想要我去探索 DDD ，让我去吃螃蟹，我看了很多文章，不能够理解 DDD 的意义。大佬你能用通俗易懂的话告诉我，你用了 DDD 后，给你带来的好处？体现在哪里？例如新增需求了，和不用 DDD 有什么不一样。你说的“添加功能容易多了”，具体呢？

[frank1256]

@coolair 话都是真话，事也都是真事，人总得吃饭，得了解一下，才能吹

[thinkershare]

@frank1256 DDD 的好处是通用语言可以保持业务一致性(这个就是第一道门槛, 越复杂的项目中, 很多术语大家没有天然形成共识, 是需要需求方, 业务专家, 开发者多方探讨, 最终达到一致性的: 说人话就是对同一个概念大家表述的是同一个东西, 这一点小项目看不出来啥优点, 但项目越复杂, 概念就会越不清晰). 子域(领域上下文)会强迫你思考如何将不相关的业务的实体分离到不同上下文, 这样你就没办法使用强一致性的方式直接操作这个对象, 而是必须去思考如何平衡 CAP. 另外他也会让你逐步学会思考使用关系模型(E-R)构建的面向对象模型是否合理, 如果你一开始就是使用的 MongoDB 这种数据库, 你就会更加深入理解对象的相互引用关系(引用即依赖, 依赖是重度耦合, 会带来很多问题). 这个话题太大, 不是几句话就可以说的清楚的....

[thinkershare]

@frank1256 凡事都有代价, 没有银弹, 学习一门技术, 重要的是理解它解决了什么问题, 带来了什么问题, 这样才能在项目中合理使用, DDD 适合业务特别复杂, 模型众多, 模型行为丰富, 重行为而非重数据的项目. 很多互联网公司的业务一点也不复杂, 只是规模庞大罢了, 那些项目用 DDD 可能没啥好处, 反而为了追求极致的性能, 使用事务脚本, 甚至裸写 SQL 这样反而更加合适.

[twing37]

咦.没想到这么靠前,竟然看到想看到的答案. @thinkershare
这位兄弟说的是应该思考实践过的.
有些人认为 ddd 先行,在我看来并不是的.
和 mvc 这种并行,是错误的观念.他只是一个辅助分支的模式.
他是一个在架构设计完整下的补充.也就是说他不会带来一个完整的架构.
不要沉迷这个东西.从另一个观点来说,一个你搜遍全网也没获得完整知识架构情况下,
只能通过只言片语靠硬思考的所谓概念.自信点,这货并不那么靠谱.

[frank1256]

@thinkershare 感谢解答

[undefine2020]

为什么你们说的每一个字我都认识，放在一起就不知所云了？

[gowk]

@thinkershare 这上面遇到个.NET 开发不容易

[coldear]

一种建模的方法，从业务需求出发，主要关注哪些模型是强相关，哪些属性是要暴露。

[ClericPy]

同样看了 DDD 才发现自己是个 DD, 以前 OOP 都写的太普通了, 早点读这些书少写不少屎山

只看前言部分已经启发很大, 似乎是那种非强范式但是可以部分参考的思考方式

[yzbythesea]

@frank1256

老哥可以直译下这篇文章，你立马就在经理眼中是 DDD 专家了
https://eng.uber.com/microservice-architecture/

[DaPanda]

我个人感觉也是 DDD 就像业务上的 OOP 。所以对它的理解不能只限于编码层面，也要考虑到团队协作，开发流程优化。

编码层面最有用的启发可能是对改善模型的设计：提供哪些接口，哪些逻辑适合放在模型自身行为里哪些应该放进更上面的层级等等。这样能让业务复杂的代码依赖关系更清晰，状态管理更统一。

我记得 Jimmy Bogard 的博客里有一系列实操性比较强的 DDD 代码重构相关博文。

[wd]

比如我想做一个卖衣服的商城，请问各位专家，ddd 在这里面能起什么作用？

[yule111222]

写了一年多的 DDD 了，很舒服，推荐一本书《解构领域驱动设计》
让 OOP 回到它应有的样子

[wangpugod2003]

@wd DDD 核心是 domain ，domain 相当于抽象出了你核心的 business 模块，剩下的表示层、数据库 DTO 层都是从属。这样带来的好处是表示层、数据库层和 domain 层完全解耦，数据库的结构变化不影响 business ，表示层更是可以自己实现 aggregate 各 domain 层，提供数据 view 出去(和三层架构 MVC 对比)。业务功能开发程序员可以专注于实现 business logic 。

当然，任何好处都是 trade off 的，带来的弊端是 data model 需要在表示层、domain 层和 DTO 层频繁转换，对性能可能有一些影响。另外，如何更好的 DDD 设计，特别是 domain 的设计、聚合根、实体类的设计，都需要摸索。

可以看一下目前的 DDD 典型架构，洋葱模型和六边形模型，JAVA 的 demo 到处都是。

[thinkershare]

@gowk 我啥都做, 什么技术合适用什么, Android/iOS//Java/Python DL/ 微信小程序, 看公司的需求, 什么乱七八糟都要学一点. 不过终究还是在.NET 技术栈花的时间最近. 我在做的属于传统行业, 业务逻辑复杂, 但并发有限, 项目需要常年维护, 我现在做的项目已经开发了快 15 年了, NET 还是有很多存量应用, 主要是 Core 出来后, 原来想要转型的项目现在也没有动力了.

[specita]

一般我听到 DDD 无非两种场合，1. 新领导空降来指点江山的时候用 2.项目要重构的时候说 DDD 有多么的好。 但是最终执行出来的往往还是分层模型，我觉得 DDD 理念很好，价值也有，但是必须要在一个大的团队里至上而下的都能理解和执行才能造得出来，不然就是感觉在吹牛逼了。

[putin541]

有一个好处就是要让 PO 说出很“清晰”，你能“听懂”的话

[shyrock]

DDD 的故事很理想。
业务分析师（甚至客户专家）要理解技术的基本思路，以及为技术抽象的原因。
而技术专家和软件架构师要理解业务的核心逻辑，并跟业务分析师一起探索找到同时满足业务抽象和技术抽象的模型。

说实话，这种跨界精通的人很难找到。
并且为了让这个统一的模型不是灵光一现，需要双方在项目迭代过程中不断重复沟通和探索过程，维护这个一致性模型的成本是非常高昂的。

[yogogo]

看了看楼上的解答，说了又好像没说一样

[zyy314680012]

是一种设计方案

[encro]

基本所有软件工程思想最后都逃离不过一个思路“简化”，而简化的一个主要思路是提供更少接口和功能。

我理解的 DDD 核心思想：

将某个领域的问题抽象，使之能够独立出来，规划好与其他业务结合点，以便降低其耦合度，增加其复用度。

DDD 是对以上思想的实践探索。

[dk7952638]

DDD 很多概念缺乏业界成熟的工具与框架，需要丰富的领域知识，比如充血模型的设计，事件溯源的实现等等，如果没有大量的业务实践也技术积累，盲目使用基本就是给自己和团队找麻烦

[Hanggi]

DDD 那本书的中间有句话很重要。

"DDD 只有在复杂的逻辑场景中才能发挥他的威力"

而显示当中大部分工作是简单重复的，所以现实场景中 DDD 能带来的收益很有限。
更多是一种美化绩效的一种手段。

[BeautifulSoap]

说真的 DDD 这东西是，你没一定的项目经验是无法理解它有什么作用的
没经历过项目里的种种问题和项目管理规划的混乱，以及面对复杂业务时只能想到把代码写成一坨的经验的话，是没法理解 DDD 里面那么多经验是干嘛得

就比如 DDD 一开始就无数次强调领域内要统一通用语言。如果你没在项目中吃过不统一通用语言的亏的话，是根本体会不到 DDD 为什么这么不厌其烦强调通用语言得重要性。
举个小例子，在编写项目的内部文档的时候我明确要求把项目中某个名词(这个词非常日常和常见)的定义加到通用语言集中。项目成员都觉得这个词语这么常用是个人都懂，要加个毛啊。然后，另一个项目中也用到了同样的名词但意思和当前项目完全不同，因为一个名词理解的差异导致两个项目成员在初期交流的时候出了非常多问题。两边都觉得这个词这么常用，对面理所当然能理解。经过这件事之后，项目的成员们都不再反对加名词定义这事了。

[lokya]

业务耦合性强的 DDD 蛮合适

[chihiro2014]

DDD 更多的是管理的重要性把。层层解耦

[ZSeptember]

面向业务

[ratalsenrty]

业务建模用

[madeworldbetter]

理论还是不错的，但是还是有落地的问题，就我所在企业来说，敏捷啥的都搞过，但是最后没啥卵用，领导期望引入新的概念解决自身管理的问题，归结为一个领导 kpi 而已，可以宣称自己在进步，在改进，至于有没有用另说，反正下面执行就是了。

[midknight]

懂的懂

[tohuer00]

DDD 是试图解决超复杂业务场景建模的一种方法，这东西十几年前国内就有人在研究了，但是实施落地非常难。
这几年随着微服务这阵风又热起来了，个人认为是因为早些年互联网的业务其实还算简单，不需要用到这些复杂的业务建模理论。后来业务越来越复杂于是微服务兴起，但是就微服务本身而言只是一套技术架构，并不是说无脑套用就能解决一切。最后还是要回到软件工程的一些基本问题，于是 DDD 又被重新拾起。

[GiantHard]

以下内容节选自 [《读〈领域驱动设计〉有感》]( https://gianthard.rocks/a/24)，是我几年前读书后写的总结，希望对你有所帮助。

## DDD 解决的问题是什么？

> 例如开发团队一开始不太理解电子电路设计相关的知识，导致做出来的东西让客户感觉很奇怪，而且没法适应业务的变化。……作者给出的解释是，开发人员对业务没有深入的理解。……应对这个问题的解决方案就是对业务领域进行建模。

## 什么是聚合根

> 我们把几个关联度较高的对象划分成一个聚合，每个聚合中有一个小组长，我们把小组长叫做聚合根（ Root ）……聚合除了管理对象生命周期之外还有贯彻落实业务规则的能力

## 业务是否需要包含自身的 CRUD ？

> 数据持久化在大部分的项目中可以说是一个非常常见的操作了，但是这一操作往往涉及到对数据库相关软件包的依赖，这将极大的破坏领域模型的纯洁性。……为此，我们将向领域层中引入新的模型——仓储。

## 代码如何分层？

> 实现分离领域模型的技术我们非常的熟悉，就是分层架构。作者建议，应该将项目代码按照“用户界面层”、“应用层”、“领域层（模型层）”、基础设施层进行划分。

[xiangwan]

推荐这个帖子里的连接 https://v2ex.com/t/665465

[frank1256]

@GiantHard 感谢解答

[xiangwan]

分享下最近的实践

- 划分好“界限上下文” 对建模时“清晰地思考” 有很大的帮助
- 分离 persistence model 和 domain model ，可以不受 ORM 的限制（ Object–relational impedance mismatch ），“自由”地建模。业务逻辑不应该受限于存储方式。
- 设计领域模型，而不是数据表 -- [via]( https://blog.sapiensworks.com/post/2013/11/19/EF-Code-First-Is-Bad-For-Your-Domain.aspx)

[sky3hao]

在我看来 DDD 是一种设计思想, 在微服务规划, 以及业务源码的规划上有很多有意义的指导作用. 其实没必要严格实践 DDD, 也很少严格 DDD 规范的开发公司和项目, 他提出的 统一领域语言, 实体, 上下文边界, 分层模型 等概念在实际开发中很有帮助. 能根据实际情况在某些方面实践或者统一规范就可以了.

[zhw2590582]

Design Driven Development

[treeboy]

Deadline-Driven Development

[jeffhong]

复杂业务建模用的，并造了一堆词

[libook]

个人理解，微服务已经流行很多年了，那么如何划分微服务比较合理呢？ DDD 就是一种可以参考的方式。

感觉这个东西还在炒作期，没有足够的落地经验，主要还是看企业目前生产过程中有啥问题，再看 DDD 能否解决这个问题。另外 DDD 不是纯开发人员的事情，产品、开发、QA 都要以领域专家为中心去开展 DDD 工作，这个得部门上下贯彻才行。

[belin520]

带弟弟

[freefcw]

DDD 这个东西。。。真不是个人能扛得动的。但熟练运用 DDD ，对于个人写项目也是有极大的好处。

在正常的项目里面，就像上面说的，分为战术和战略两种，战术上其实就是你的类的关系，类和类之间为什么有依赖，为什么应该解依赖。

从战略层面上，就是业务和业务之间的关系，简单的说，用户有订单，订单有用户，但是用户和订单是两个领域。考虑到其他各个地方都有用户，如客服，游戏，退货，这些用户有什么区别，其实是不同上下文里面的所谓用户，本质是不一样的，只有理清楚业务之间的关系，才能设计出良好架构的模块，而这也是微服务划分的关键，界限，上下文。。

DDD 还是好东西，但在公司里面，需要整体配合

[cp19890714]

个人理解：
DDD 是面向对象的实践总结。
我们在工作中，不必拘泥于 DDD ，不一定要遵守公认的 DDD 的开发模式，只需要使用其中的部分思想就会有很大帮助。
例如：帮助梳理业务流程，帮助团队间更好沟通等等。

[cp19890714]

DDD 难以落地的原因在于，它不是某项技术，而是思想。非常依赖于团队中关键成员的个人能力。
技术框架是看得见，摸得着的，只要不傻，就能入门。但思想不行。

[ufan0]

对同事要求太高，落地十分困难，并且维护不力的话，会是一个四不像，巨坑。

[lanlanye]

楼上说的对，对同事要求太高，需要你做架构师

[jeesk]

DDD 阿里有开源的框架， 你可以看看淘宝技术官方博客写的东西。 我是看了不少， 但是总觉得自己的业务代码套不上去， 太 tm 难受了， 有种别人给你大炮你只能玩驳壳枪的感觉。

[xmsz]

我也是一头雾水 然后

作为产品和技术，我感觉我的理解力居然不够用了？ 本来我都是用产品的方法论写代码，利用业务的理解和抽象写代码很轻松而且维护简单

但是一碰到 DDD 我感觉用产品和技术都理解不了...


然后还有我公司的技术负责人水平很一般，他肯定更不能理解... 那就完全推进不了
而且他对于业务真的『毫无用户感知』能力

这个也是我担忧的一点，就是如果只是简单的逻辑剥离，那没是个程序员一般没问题。
如果对于有经验的程序员来说，无非懂得更抽象化一点。

但是对于业务，又不是技术的能力要求... 而且技术和业务思考的维度真的差别蛮大的...

让技术根据业务设计这个事情我就觉得是伪命题...

[xykjlcx]

@jeesk 我也是这种赶紧，尤其是面向对象的设计、与结构化数据存储之间的差异 导致很多问题想不透彻

[MadDave]

当下大部分写出来的流水线式的代码在 DDD 面前就是堆辣鸡，领悟了 DDD 你才能发现面向对象和程序描述世界的本质