领域驱动设计(简介)

在微服务下根据不同业务进行划分从而产生专注服务于特定业务的不同系统。不同系统之间相互配合从而完成整体业务功能。在根据业务进行划分时候，目前我们大部分人采用的是数据模型驱动开发的模式，在这种模式下业务和数据之间的流转其实是通过biz层处理的。这样的模型结构将业务的流转放到了biz层中和系统进行强耦合，然而在现实生活中业务的不确定性和易变性导致我们需要不断的修改数据模型和biz层。一段时间迭代后biz层和数据模型通过不同的需求迭代导致必须要通过功能去查看代码从而还原业务。在这样的情况下，领域驱动这种方式就很适合现在的开发流程。以下大部分是根据www.jdon.com中的一系列领域驱动设计的文章沉淀下来。感谢jdon.com

领域驱动设计是什么？

领域驱动设计（英语：Domain-driven design，缩写 DDD）是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。

领域驱动设计的前提是：

1. 把项目的主要重点放在核心领域（core domain）和域逻辑;
2. 把复杂的设计放在有界域（bounded context）的模型上;
3. 发起一个创造性的合作之间的技术和域界专家以迭代地完善的概念模式，解决特定领域的问题

领域驱动设计的由来

服务器后端架构发展主要分为三个阶段：

1. UI+DataBase的两层架构
2. UI+Service+DataBase的多层SOA架构
3. DDD+SOA服务的事件驱动架构
   架构的升级是由于对后端技术的需求倒逼导致的，从最开始的静态网站到Ajax技术为代变的动态网站，再到现在的微服务架构。不断的迭代的需求引领这工程实践向DDD的模式。

领域取属设计能做什么？

领域驱动设计主要是用领域模型去描述业务，传统的J2EE和Spring+持久化层等事务性编程模型是基于数据去实现的也就只会关心数据的结构，从而导致业务对象(DTO/BO)等只存在get/set方法。

以下是jdon的经典比喻：

以比赛Match为案例，比赛有“开始”和“结束”等业务行为，但是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中，而不是放在比赛对象本身之中。我们不能因为用了计算机，用了数据库，用了框架，业务模型反而被技术框架给绑架;

提倡充血模型，实际就是让过去被肢解被黑crack的业务模型回归正常，当然这也会被一些先入为主或被洗过脑的程序员看成反而不正常，这更是极大可悲之处。看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。

总结

我理解的意思是领域驱动模型是向让我们按照业务来进行建模，而不是业务最后产生的数据来进行数据建模。数据建模会让我们的业务被隐藏在service中，业务产生的结果是我们得到的数据。用领域模型达到的效果就是模型即代表业务，也就是看到模型就能知道业务，从业务出发，然后用行为和数据去完成业务的方法。