DDD 到底啥，有啥用

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

我理解的 DDD 核心思想：

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

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

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

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

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

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

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

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

业务耦合性强的 DDD 蛮合适

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

面向业务

业务建模用

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

懂的懂

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

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

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

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

## 什么是聚合根

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

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

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

## 代码如何分层？

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

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

@GiantHard 感谢解答

分享下最近的实践

- 划分好“界限上下文” 对建模时“清晰地思考” 有很大的帮助
- 分离 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)

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

Design Driven Development

Deadline-Driven Development

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

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

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