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

作者:xinwang_m@163.com
发布时间: 2020-07-20 05:36:59 (3年前)
关键词: 领域驱动设计；DDD
摘要:

                              
                                     过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化

# 领域驱动设计(DDD:Domain-Driven Design)
Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，本站Jdon.com是国内公开最早讨论DDD网站之一，可订阅DDD专题。初学者学习DDD可从研究本站Jdon框架的DDD应用源码开始，戳这里开始。
　　过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。

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

![](/user/files/hDOXq4as1zvIs7vWQRM0LJe-smB4uqSB9IvMDcWqcWA.png)

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

1. 1、UI+DataBase的两层架构，这种面向数据库的架构(上图table module )没有灵活性。
2. 2、UI+Service+DataBase的多层SOA架构，这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差，见[Spring Web 应用的最大败笔](http://xmanong.com/ii/4475 "Spring Web 应用的最大败笔")
3. 3、DDD+SOA微服务的事件驱动的[CQRS读写分离架构](http://xmanong.com/ii/4476 "CQRS读写分离架构")，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。

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

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

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

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

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

DDD落地实现离不开Clean架构、六边形架构、 CQRS、Event Source几大大相关领域。下图是传统以数据库为中心的架构与使用DDD实现以领域为中心架构的区别。

![](/user/files/M4fDMNDgV1vi7jmsjq3QsPPuqCaoBD_mE7OCSyGWSvA.png)

DDD专门为解决复杂性而诞生，因此解决思路完全不同于传统的CRUD，但是DDD本身掌握起来并不会感觉复杂，从程序员角度看，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。

## 重点资讯
- 　[DDD设计入门建模流程](http://xmanong.com/ii/4477 "DDD设计入门建模流程")
- 　[领域驱动设计参考](http://xmanong.com/ii/4478 "领域驱动设计参考")
- 　[领域驱动设计简介](http://xmanong.com/ii/4479 "领域驱动设计简介")
- 　[聚合与一致性和有界上下文](http://xmanong.com/ii/4480 "聚合与一致性和有界上下文")
- 　[函数式DDD架构入门 - SCOTT WLASCHIN](http://xmanong.com/ii/4481 "函数式DDD架构入门 - SCOTT WLASCHIN")

------------

# 教程与文章
- [板桥大话DDD](http://xmanong.com/ii/4483 "板桥大话DDD")
用大白话简单谈谈DDD的一些基础特点，只是扫盲！数据库SQL强人慎入

- [业务代码编程陷阱案例 - jaxenter](http://xmanong.com/ii/edit/4487 "业务代码编程陷阱案例 - jaxenter")
非常普遍的不恰当的编程方式，失血模型导致的陷阱

- [类与数据结构的比较！每个优秀的软件设计师和架构师都需要牢记的问题](http://xmanong.com/ii/4437 "类与数据结构的比较！每个优秀的软件设计师和架构师都需要牢记的问题")

- [如何构建基于DDD领域驱动的微服务？](http://xmanong.com/ii/edit/4488 "如何构建基于DDD领域驱动的微服务？")

- [关于有界上下文和微服务的关系以及它们的划分粒度](http://xmanong.com/ii/4489 "关于有界上下文和微服务的关系以及它们的划分粒度")

- [切实有效的三个步骤：如何通过划分有界上下文设计微服务？](http://xmanong.com/ii/4490 "切实有效的三个步骤：如何通过划分有界上下文设计微服务？")

- [面向对象建模与数据库建模两种分析设计方法的比较](http://xmanong.com/ii/4491 "面向对象建模与数据库建模两种分析设计方法的比较")
数据库驱动设计与对象建模是决定软件不同命运的两大派别，谁可以让软件更具有生命，维护拓展更方便？伸缩性更强?

- [对象和关系数据库的天然阻抗](http://xmanong.com/ii/4492 "对象和关系数据库的天然阻抗")
软件是讲究方法的，要谈方法，这个世界只有两种：一是将复杂问题简单化的方法；另一是将简单问题复杂化的方法。对于软件这个领域，你只能选择前者。

- [面向对象与领域建模](http://xmanong.com/ii/4493 "面向对象与领域建模")
据调查，目前有70%左右程序员是在使用OO语言编写传统过程化软件，缺乏完整的面向对象思维方法的教育和培训是基本根源，本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点

- [Evans DDD 领域建模](http://xmanong.com/ii/4494 "Evans DDD 领域建模")
如何提炼模型，而不是数据表，进而精化模型对象，使其能够反映领域概念基本本质是一个复杂过程，Evans DDD是2004年提出的具备革命性影响的软件思想。

- [实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)](http://xmanong.com/ii/4495 "实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)")
领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道。

- **[领域模型驱动设计(Evans DDD)之模型提炼](http://xmanong.com/ii/4494 "领域模型驱动设计(Evans DDD)之模型提炼")**

- [软件建模设计](http://xmanong.com/ii/4496 "[软件建模设计]")

- [如何从职责和协作中发现丰富的充血对象？](http://xmanong.com/ii/4497 "[如何从职责和协作中发现丰富的充血对象？]")
失血模型贫血模型是DDD最大敌人，如何根据SOLID原则和GRASP原则设计业务行为？本文给出了DDD具体实践中一些具体细节，是和DDD配合一起进行面向对象分析设计的好方法。

- [业务模型统一描述](http://xmanong.com/ii/4498 "业务模型统一描述")
统一语言是DDD一个重要特征和重点。
Domain Events异步应用
领域驱动设计和异步架构完美实战解决之道。

- [DDD DCI和领域事件](http://xmanong.com/ii/4499 "DDD DCI和领域事件")
将DDD DCI Event sourcing结合在一个案例中，展示OOA和OOD实现过程，直至可运行的源代码。

- [业务建模：CQRS应用场景 ](http://xmanong.com/ii/4500 "业务建模：CQRS应用场景 ")
如何更好地在实践中实现DDD，又防止技术架构对业务领域的侵害，本文讨论引入CQRS使用场景。

- [不变性immutablity设计](http://xmanong.com/ii/4501 "不变性immutablity设计")
不变性是统领业务分析和高性能架构重要法门，通过业务上不变性分析设计，可以实现代码运行的并发高性能和高扩展性

- [事件、契约设计与BDD](http://xmanong.com/ii/4502 "事件、契约设计与BDD")
板桥banq提出中西结合的统一语言：场景 事件和状态，该文进行了论证。

- [DDD CQRS和Event Sourcing的案例：足球比赛](http://xmanong.com/ii/4503 "DDD CQRS和Event Sourcing的案例：足球比赛")
DDD + CQRS + Event Sourcing实现案例，结合代码与理论讲解。

- [集装箱车队系统的DDD案例](http://xmanong.com/ii/4504 "集装箱车队系统的DDD案例")
为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。

- [DDD仓储实现：Spring Data JDBC教程](http://xmanong.com/ii/4505 "DDD仓储实现：Spring Data JDBC教程")

- [不使用DDD的后果：为什么我们停止了向微服务的迁移？](http://xmanong.com/ii/4506 "不使用DDD的后果：为什么我们停止了向微服务的迁移？")

- [使用DDD聚合发现隐藏的业务规则的案例分析：数据库事务的业务实现](http://xmanong.com/ii/4507 "使用DDD聚合发现隐藏的业务规则的案例分析：数据库事务的业务实现")

- [向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？](http://xmanong.com/ii/4508 "向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？"),<h1 id="h1--ddd-domain-driven-design-"><a name="领域驱动设计(DDD:Domain-Driven Design)" class="reference-link"></a>领域驱动设计(DDD:Domain-Driven Design)</h1>Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，本站Jdon.com是国内公开最早讨论DDD网站之一，可订阅DDD专题。初学者学习DDD可从研究本站Jdon框架的DDD应用源码开始，戳这里开始。 　　过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。
　　DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较：
 <img src="/user/files/hDOXq4as1zvIs7vWQRM0LJe-smB4uqSB9IvMDcWqcWA.png" alt="">
服务器后端发展三个阶段：
<ol>
<li>1、UI+DataBase的两层架构，这种面向数据库的架构(上图table module )没有灵活性。</li><li>2、UI+Service+DataBase的多层SOA架构，这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差，见<a href="http://xmanong.com/ii/4475" title="Spring Web 应用的最大败笔">Spring Web 应用的最大败笔</a></li><li>3、DDD+SOA微服务的事件驱动的<a href="http://xmanong.com/ii/4476" title="CQRS读写分离架构">CQRS读写分离架构</a>，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。</li></ol>
DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？
　　以比赛Match为案例，比赛有“开始”和“结束”等业务行为，但是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中，而不是放在比赛对象本身之中。我们不能因为用了计算机，用了数据库，用了框架，业务模型反而被技术框架给绑架，就像人虽然是由母亲生的，但是人的吃喝拉撒母亲不能替代，更不能以母爱名义肢解人的正常职责行为，如果是这样，这个人就是被母爱绑架了。
　　提倡充血模型，实际就是让过去被肢解被黑crack的业务模型回归正常，当然这也会被一些先入为主或被洗过脑的程序员看成反而不正常，这更是极大可悲之处。看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。
　　DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。
DDD是解决复杂中大型软件的一套行之有效方式，在国外已经成为主流。DDD认为很多原因造成软件的复杂性，我们不可能避免这些复杂性，能做的是对复杂的问题进行控制。而一个好的领域模型是控制复杂问题的关键。领域模型的价值在于提供一种通用的语言，使得领域专家、产品经理和软件技术人员联系在一起，沟通无歧义。
　　DDD落地实现离不开Clean架构、六边形架构、 CQRS、Event Source几大大相关领域。下图是传统以数据库为中心的架构与使用DDD实现以领域为中心架构的区别。
<img src="/user/files/M4fDMNDgV1vi7jmsjq3QsPPuqCaoBD_mE7OCSyGWSvA.png" alt="">
DDD专门为解决复杂性而诞生，因此解决思路完全不同于传统的CRUD，但是DDD本身掌握起来并不会感觉复杂，从程序员角度看，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。
<h2 id="h2-u91CDu70B9u8D44u8BAF"><a name="重点资讯" class="reference-link"></a>重点资讯</h2><ul>
<li>　<a href="http://xmanong.com/ii/4477" title="DDD设计入门建模流程">DDD设计入门建模流程</a></li><li>　<a href="http://xmanong.com/ii/4478" title="领域驱动设计参考">领域驱动设计参考</a></li><li>　<a href="http://xmanong.com/ii/4479" title="领域驱动设计简介">领域驱动设计简介</a></li><li>　<a href="http://xmanong.com/ii/4480" title="聚合与一致性和有界上下文">聚合与一致性和有界上下文</a></li><li>　<a href="http://xmanong.com/ii/4481" title="函数式DDD架构入门 - SCOTT WLASCHIN">函数式DDD架构入门 - SCOTT WLASCHIN</a></li></ul>
<hr>
<h1 id="h1-u6559u7A0Bu4E0Eu6587u7AE0"><a name="教程与文章" class="reference-link"></a>教程与文章</h1><ul>
<li><a href="http://xmanong.com/ii/4483" title="板桥大话DDD">板桥大话DDD</a> 用大白话简单谈谈DDD的一些基础特点，只是扫盲！数据库SQL强人慎入
</li><li><a href="http://xmanong.com/ii/edit/4487" title="业务代码编程陷阱案例 - jaxenter">业务代码编程陷阱案例 - jaxenter</a> 非常普遍的不恰当的编程方式，失血模型导致的陷阱
</li><li><a href="http://xmanong.com/ii/4437" title="类与数据结构的比较！每个优秀的软件设计师和架构师都需要牢记的问题">类与数据结构的比较！每个优秀的软件设计师和架构师都需要牢记的问题</a>
</li><li><a href="http://xmanong.com/ii/edit/4488" title="如何构建基于DDD领域驱动的微服务？">如何构建基于DDD领域驱动的微服务？</a>
</li><li><a href="http://xmanong.com/ii/4489" title="关于有界上下文和微服务的关系以及它们的划分粒度">关于有界上下文和微服务的关系以及它们的划分粒度</a>
</li><li><a href="http://xmanong.com/ii/4490" title="切实有效的三个步骤：如何通过划分有界上下文设计微服务？">切实有效的三个步骤：如何通过划分有界上下文设计微服务？</a>
</li><li><a href="http://xmanong.com/ii/4491" title="面向对象建模与数据库建模两种分析设计方法的比较">面向对象建模与数据库建模两种分析设计方法的比较</a> 数据库驱动设计与对象建模是决定软件不同命运的两大派别，谁可以让软件更具有生命，维护拓展更方便？伸缩性更强?
</li><li><a href="http://xmanong.com/ii/4492" title="对象和关系数据库的天然阻抗">对象和关系数据库的天然阻抗</a> 软件是讲究方法的，要谈方法，这个世界只有两种：一是将复杂问题简单化的方法；另一是将简单问题复杂化的方法。对于软件这个领域，你只能选择前者。
</li><li><a href="http://xmanong.com/ii/4493" title="面向对象与领域建模">面向对象与领域建模</a> 据调查，目前有70%左右程序员是在使用OO语言编写传统过程化软件，缺乏完整的面向对象思维方法的教育和培训是基本根源，本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点
</li><li><a href="http://xmanong.com/ii/4494" title="Evans DDD 领域建模">Evans DDD 领域建模</a> 如何提炼模型，而不是数据表，进而精化模型对象，使其能够反映领域概念基本本质是一个复杂过程，Evans DDD是2004年提出的具备革命性影响的软件思想。
</li><li><a href="http://xmanong.com/ii/4495" title="实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)">实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)</a> 领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道。
</li><li><a href="http://xmanong.com/ii/4494" title="领域模型驱动设计(Evans DDD)之模型提炼">领域模型驱动设计(Evans DDD)之模型提炼</a>
</li><li><a href="http://xmanong.com/ii/4496" title="[软件建模设计]">软件建模设计</a>
</li><li><a href="http://xmanong.com/ii/4497" title="[如何从职责和协作中发现丰富的充血对象？]">如何从职责和协作中发现丰富的充血对象？</a> 失血模型贫血模型是DDD最大敌人，如何根据SOLID原则和GRASP原则设计业务行为？本文给出了DDD具体实践中一些具体细节，是和DDD配合一起进行面向对象分析设计的好方法。
</li><li><a href="http://xmanong.com/ii/4498" title="业务模型统一描述">业务模型统一描述</a> 统一语言是DDD一个重要特征和重点。 Domain Events异步应用 领域驱动设计和异步架构完美实战解决之道。
</li><li><a href="http://xmanong.com/ii/4499" title="DDD DCI和领域事件">DDD DCI和领域事件</a> 将DDD DCI Event sourcing结合在一个案例中，展示OOA和OOD实现过程，直至可运行的源代码。
</li><li><a href="http://xmanong.com/ii/4500" title="业务建模：CQRS应用场景 ">业务建模：CQRS应用场景 </a> 如何更好地在实践中实现DDD，又防止技术架构对业务领域的侵害，本文讨论引入CQRS使用场景。
</li><li><a href="http://xmanong.com/ii/4501" title="不变性immutablity设计">不变性immutablity设计</a> 不变性是统领业务分析和高性能架构重要法门，通过业务上不变性分析设计，可以实现代码运行的并发高性能和高扩展性 
</li><li><a href="http://xmanong.com/ii/4502" title="事件、契约设计与BDD">事件、契约设计与BDD</a> 板桥banq提出中西结合的统一语言：场景 事件和状态，该文进行了论证。
</li><li><a href="http://xmanong.com/ii/4503" title="DDD CQRS和Event Sourcing的案例：足球比赛">DDD CQRS和Event Sourcing的案例：足球比赛</a> DDD + CQRS + Event Sourcing实现案例，结合代码与理论讲解。
</li><li><a href="http://xmanong.com/ii/4504" title="集装箱车队系统的DDD案例">集装箱车队系统的DDD案例</a> 为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。
</li><li><a href="http://xmanong.com/ii/4505" title="DDD仓储实现：Spring Data JDBC教程">DDD仓储实现：Spring Data JDBC教程</a>
</li><li><a href="http://xmanong.com/ii/4506" title="不使用DDD的后果：为什么我们停止了向微服务的迁移？">不使用DDD的后果：为什么我们停止了向微服务的迁移？</a>
</li><li><a href="http://xmanong.com/ii/4507" title="使用DDD聚合发现隐藏的业务规则的案例分析：数据库事务的业务实现">使用DDD聚合发现隐藏的业务规则的案例分析：数据库事务的业务实现</a> 
</li><li><a href="http://xmanong.com/ii/4508" title="向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？">向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？</a>
</li></ul>

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论