前言：在一次项目中，我们新来了一位技术经理他在刚接触项目时发现我们框架使用的是传统的mvc模型（一直的用的就是这种模型开发),于是将我们的项目基础架构重新搭建了一番，并引出DDD领域驱动设计思想。
1、什么是DDD领域驱动设计思想
刚一开是经理问我了解过DDD领域驱动设计，当时一脸懵逼完全没有听过呀（两年工作的萌新，嘿嘿）在网上也没听人讲过，所以下班之余查找了下这个设计思想。
Domain-Driven Design领域驱动设计：简称DDD是一套综合软件系统分析和设计的面向对象建模方法，是一种通过把设计实现与不断修正发展的模型紧密关联起来，来应对复杂需求的一种软件开发思路。
1.1 什么是领域（Domain）
我认为我们需要知道我们现在要做的一个什么样的系统，这个系统解决什么样的问题。任何一个系统都会有属于自己的某个特定的领域，比如论坛的是一个领域，那么你想做一个论坛它的核心业务是确定的，比如用户发帖，回帖等核心基本功能。比如一个OA办公系统，这种都属于办公体系，都是需要工作流，用户管理等核心环节。所以，同一个领域的系统都具有相同的核心业务，因此解决的问题的本质是类似的。
因此，我们可以推断出，一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。通常我们说，要成为一个领域的专家，必须要在这个领域深入研究很多年才行。因为只有你研究了很多年，你才会遇到非常多的该领域的问题，同时你解决这个领域中的问题的经验也非常丰富。很多时候，领域专家比技术专家更加吃香，比如金融领域的专家。
1.2 什么是设计（Design）
DDD中的设计主要指领域模型的设计。为什么是领域模型的设计而不是架构设计或其他的什么设计呢？因为DDD是一种基于模型驱动开发的软件开发思想，强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在。每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题。
从领域和代码实现的角度来理解，领域模型绑定了领域和代码实现，确保了最终的代码实现就一定是解决了领域中的核心问题的。因为：1）领域驱动领域模型设计；2）领域模型驱动代码实现。我们只要保证领域模型的设计是正确的，就能确定领域模型可以解决领域中的核心问题；同理，我们只要保证代码实现是严格按照领域模型的意图来落地的，那就能保证最后出来的代码能够解决领域的核心问题的。这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。
1.3 什么是驱动（Driven）
什么是驱动，驱动就是：
- 领域驱动领域模型设计。
- 领域模型驱动代码实现。这个就和我们传统的数据库驱动开发的思路形成对比了。DDD中，我们总是以领域为边界，分析领域中的核心问题（核心关注点），然后设计对应的领域模型，再通过领域模型驱动代码实现。而像数据库设计、持久化技术等这些都不是DDD的核心，而是外围的东西。
1.4 总结
- 领域就是问题域，有边界，领域中有很多问题。
- 任何一个系统要解决的那个大问题都对应一个领域。
- 通过建立领域模型来解决领域中的核心问题，模型驱动的思想。
- 领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题。
- 领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值。
- 通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题。
- 领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值。
- 技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地。
2、为什么DDD难以落地
- 从网络上查找了下 ，国内关于DDD的文档和实践案例并不是很多，除了知名的几个大厂很少看到关于DDD的落地实践。最佳实践太少意味着，我们可以参考的资料就少，承担的项目失败的风险就大。
- DDD中出现了很多的概念和术语，比如 聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等概念。很多人看到了这么多概念的时候，心中就开始打退堂鼓了。
- DDD需要我们在领域建模花费很多的时间和精力，而且还可能导致付出和收益不成正比的情况。因为在界限上下文的划分上是非常考验架构师的业务水平。如果没有将业务模型很好的识别出来，那么可能很快模型就会在迭代的过程中腐败掉了。
- 没有标准：DDD是一套思想，一套领域建模设计，一套在特定上下文环境中使用的。所以在1千个团队中实行DDD,可能有1千套不同的方案。一个实行DDD多年的人，换了一个公司，换了一个团队，把他原有的那套带过去，推行下去，一般都不适用。
因此，其只是一种设计思想，当团队有人提出来并能将其搭建，那么确实对于大型团队来说是比较方便的，将核心与业务分离开来，但是期待DDD解决所有的问题是不可能的，程序员都是很实际的，没有好处的东西是不会去做的。你必须能够有效的帮助他提升，他才会去接受。 比如当有团队成员提出来，我们实行了这一套后，是不是不用加班了？或者加班时间可以减小？
所以没有好的框架思想,只有不断学习的程序员。