阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「网络」欢迎转载，保留摘要，谢谢！

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

领域驱动设计（DDD）是一种基于模型驱动的软件设计方式。它以领域为核心，分析领域中的问题，通过建立一个领域模型来有效的解决领域中的核心的复杂问题。Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧。只有对领域的不断深入认识，才能得到一个解决领域核心问题的领域模型。如果一个应用的复杂性不是在技术方面的，而是在领域本身，即领域内的业务很复杂，那这种应用，使用领域驱动设计的价值就越大。

领域驱动开发也是一种敏捷开发过程（极限编程，XP），强调迭代开发。在迭代过程中，强调开发人员与领域专家需要保持密切的合作关系。极限编程假设我们能通过不断快速重构完善设计。所以，对开发人员的要求非常高。

领域驱动设计提出了一套核心构造块（Building Blocks，如聚合、实体、值对象、领域服务、领域工厂、仓储、领域事件，等）,这些构造块是对面向对象领域建模的一些核心最佳实践的浓缩。这些构造块可以使得我们的设计更加标准、有序。

统一语言（Ubiquitous Language），是领域驱动设计中一个非常重要的概念。任何一个领域驱动设计的项目，都需要一种通用语言，一套通用的词汇。因为没有通用的语言，就没有一致的概念，沟通就会遇到障碍，最后的领域模型和软件也就无法满足领域内的真实业务需求。通用语言是领域专家和开发人员在对领域问题的沟通、需求的讨论、开发计划的制定、领域模型的设计，以及开发人员之间对领域模型的具体编码落地实现，等一系列过程中，所有人员使用的一种通用语言。换句话说，就是无论是沟通时所用的词汇、还是领域模型中的概念、还是代码中出现的类名与方法，只要是相同的意思，那就应该使用相同的词汇。可以看出，这种通用语言不是一下子就可以形成，而是在一个各方人员讨论的过程中，不断发现、明确，与精炼出来的。

领域模型是领域驱动设计的核心。统一语言中的所有关键词汇，在领域模型上应该都能找到。各方人员沟通时，都应该以领域模型为基础。通过讨论的不断深入，大家对领域的认识也会不断深入，领域模型也会不断得到完善，统一语言的词汇也会不断丰富和精准。需要特别强调的是，开发人员应该尽量保证代码实现和领域模型相绑定，时刻保持代码与模型的一致。如果不绑定，那代码就会慢慢和模型相脱节，就会出现像我们以前那样的设计文档和代码相脱节一样的问题，甚至模型还会起到误导作用。通过这样一种思路，我们确保语言、模型、代码三者紧密绑定，确保最后实现出来的软件可以准确无误的实现业务需求，并且还能让我们的软件可以快速的和业务同时演进。而不像传统的开发方式那样，分析、设计、实现三个阶段完全脱节，最后出来的软件没有很好的满足业务需求，也不能在未来很快的跟业务需求一起演进。所以，领域模型同时承载了分析的结果和设计的结果，这里的分析是指对领域内业务需求的分析，设计是指对模型的设计以及软件的设计。所以，我们的领域模型，不能只考虑业务需求，还要同时考虑软件设计的原则，是一种综合考虑的、平衡的设计结果。

领域模型可以复用，因为特定的领域模型解决的都是某个特定的问题域；比如淘宝网有个商品中心，有个商品模型，核心概念有商品分类、商品；商品模型负责解决电子商务领域中的商品目录（Product Catalog）子域。后来阿里又出了个天猫，也会有商品中心，但是这两个商品中心基本是一样的问题域。所以，我们可以复用之前淘宝实现的商品中心领域模型，并复用之前淘宝商品中心的解决方案，来解决天猫的商品维护和展示。当然，这个只是我个人的认识，一个例子。具体阿里是否是一个商品中心同时解决淘宝和天猫的业务，没具体调研过。

Bounded Context，属于一种软件构件，作用是用来对领域模型进行划分。Bounded Context有两层含义： Bounded，即有边界的，表示领域模型有边界；这个边界定义了模型的适用范围，以便让负责该模型的团队知道什么该在模型中实现，什么不该； Context，即领域模型的产生是在某个上下文中产生的；上下文是一个和环境相关的概念。比如一次头脑风暴会议大家达成了一个模型，那这次会议的讨论就是该模型的上下文；比如某本书中谈到了某个东西，那这个东西的上下文就是那本书，那个东西要有意义的前提离不开那本书这个上下文；所以，上下文是模型有意义的前提；

领域建模的方法有很多种，大概的思路是：

通过与领域专家和业务需求人员沟通，找出领域中的关键业务场景； 针对每个业务场景分析出有哪些场景参与者，哪些参与者以对象（聚合）的形式参与，哪些参与者以服务的形式参与； 分析每个场景参与者对象的基本状态特征； 分析每个场景参与者对象分别扮演什么角色参与场景，整个场景的完整交互过程是怎样的，对象在参与场景的过程中执行了哪些交互行为； 分析如何记录和跟踪这一次交互行为，分析这次交互行为会产生哪些额外的信息；

关于领域（Domain）、领域模型（Domain Model）、边界上下文（Bounded Context）的关系

领域就是问题域，问题空间； 领域模型是一种模型，表达了领域中那些业务需求以及业务规则必须被满足； 每一个领域中的问题，都会有一个对应的领域模型去解决； Bounded Context的作用是用来对领域模型进行划分； 划分领域就是对问题空间的划分，通俗的理解，就是将大问题拆分为小问题； 划分Bounded Context就是将一个大的领域模型划分为多个小的领域模型； 可以把Bounded Context看成是一种解决方案空间，所以，Bounded Context也可以理解为是对解决方案空间的划分； 理论上，一个Domain可能会对应多个Bounded Context；同样，一个Bounded Context可能也会对应多个Domain；所以他们之间没有绝对的关系。主要是他们划分的依据不同，一个是针对领域（问题空间），一个是针对领域模型（解决方案空间）；理想情况，一个Domain最好对应一个Bounded Context；

关于Domain、Sub Domain、Core Domain、Generic Domain，以及Shared Kernal的理解：

一个领域（Domain）会拆分为多个子领域（Sub Domain）； 子领域中最核心（最重要）的那个叫Core Domain；我们应该将团队的核心资源用在核心子域上，因为它是产品成败的关键； 除了Core Domain外，其他的是支撑子域（Supporting Subdomain）； 有些支撑子域比较特殊，因为它解决的是一类通用问题，比如账号和权限；这类子域我们叫做通用子域（Generic Subdomain）；通常，通用子域对应的Bounded Context，会跨域多个子域； 多个子领域有时会有相交的部分，我们称作共享内核（Shared Kernel）；体现到代码上，就是同一份代码，在两个领域模型中复用； 一般只有Domain比较大的时候，我们才会划分出Sub Domain；

为什么一个大的领域模型需要划分？因为，通常一个大的领域模型需要多个团队合作完成。如果多个团队基于一个共同的领域模型工作，由于每个团队的关注点不同，且一些看似叫法一样的概念，对于不同的团队，其背后的意思完全不同。所以，这样的概念含义模糊会给团队以及成员之间的合作带来很大的困扰。所以，我们需要通过一种手段（Bounded Context），将领域模型划分为不同的部分，确保同一个Bounded Context内的领域模型所表达的概念含义明确。然后，同一个Bounded Context下面，相关人员都使用一种统一的语言，以此来保证团队成员之间沟通能畅通无阻。