DDD 到底啥，有啥用

[frank1256]

rt

求大佬给我指点指点。

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

[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]

是一种设计方案