领域驱动设计(DDD:Domain-Driven Design)

Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，本站Jdon.com是国内公开最先讨论DDD网站之一，可订阅 DDD专题 。 初学者学习DDD可从研究本站Jdon框架的DDD应用源码开始， 戳这里开始 。

　　过去系统分析和系统设计都是分离的，正如咱们国家“系统分析师” 和“系统设计师” 两种职称考试同样，这样割裂的结果致使，需求分析的结果没法直接进行设计编程，而可以进行编程运行的代码却扭曲需求，致使客户运行软件后才发现不少功能不是本身想要的，并且软件不能快速跟随需求变化。

　　DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件可以更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较：

　　服务器后端发展三个阶段：

1. UI+DataBase的两层架构，这种面向数据库的架构(上图table module )没有灵活性。
2. UI+Service+DataBase的三层或多层SOA架构，服务易脚本化(上图script)，伸缩性差，见这里讨论
3. DDD+SOA的事件驱动的CQRS读写分离架构，应付复杂业务逻辑　　

　　DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？

　　以比赛Match为案例，比赛有“开始”和“结束”等业务行为，可是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中，而不是放在比赛对象自己之中。咱们不能由于用了计算机，用了数据库，用了框架，业务模型反而被技术框架给绑架，就像人虽然是由母亲生的，可是人的吃喝拉撒母亲不能替代，更不能以母爱名义肢解人的正常职责行为，若是是这样，这我的就是被母爱绑架了。

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

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

　　DDD是解决复杂中大型软件的一套行之有效方式，在国外已经成为主流。DDD认为不少缘由形成软件的复杂性，咱们不可能避免这些复杂性，能作的是对复杂的问题进行控制。而一个好的领域模型是控制复杂问题的关键。领域模型的价值在于提供一种通用的语言，使得领域专家和软件技术人员联系在一块儿，沟通无歧义。

　　DDD的实现离不开in-memory缓存、 CQRS、 DCI、 EDA或Event Source三大相关领域。