本文主要是介绍02.领域驱动设计：了解领域、子域、核心域、通用域、支撑域、通用语言和限界上下文，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
概要
1、领域
2、子领域
建立领域模型步骤：
3、核心域
4、通用域
5、支撑域
6、思考题
7、通用语言
8、限界上下文
限界上下文和微服务的关系
9、总结
限界上下文在微服务设计中的作用和意义是什么
概要
领域驱动设计（DDD）的知识体系提出了很多的名词，比如：领域、子域、核心域、通用域、支
撑域、限界上下文、聚合、聚合根、实体、值对象等等。这些名词，都是关键概念，这些名词在你
的微服务设计和开发过程中不一定都用得上，但它可以帮你理解DDD的核心设计思想和理念。而
这些思想和理念，在IT战略设计、业务建模和微服务设计中都是可以借鉴的。
1、领域
领域就是用来确定范围的，范围即边界，这是DDD在设计中不断强调边界的原因。
在研究和解决业务问题时，DDD会按照一定的规则将业务领域进行细分，当领域细分到一定的程
度后，DDD会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该
领域模型，解决相应的业务问题。
简言之，DDD的领域就是这个边界内要解决的业务问题域。
2、子领域
领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的
问题域或更小的业务范围。
DDD是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂度。
面对错综复杂的业务领域，DDD是如何使业务从复杂变得简单，更容易让人理解，技术实现更容
易呢？
DDD的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的
做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域
的知识体系。当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了。
建立领域模型步骤：
-
第一步：确定研究对象，即研究领域。
-
第二步：对研究对象进行细分。
-
第三步：将子域进一步细分为多个子域的过程。
-
第四步：确定了研究的最小边界。
确定微服务内功能要素和边界的过程。
每一个细分的领域都会有一个知识体系，就是DDD的领域模型。
在所有子域的研究完成后，我们就建立了全域的知识体系了，也就建立了全域的领域模型。
领域建模和微服务建设的过程和方法基本类似，其核心思想就是将问题域逐步分解，降低业务理解
和系统实现的复杂度。
3、核心域
在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为
三类子域，它们分别是：核心域、通用域和支撑域。
决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。
4、通用域
没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。
5、支撑域
还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的
子域，它就是支撑域。
这三类子域相较之下，核心域是最重要的。
通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认
证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具
有企业特性，但不具有通用性，
例如数据代码类的数据字典等系统。
很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点
会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。
如果你的公司刚好有意向转型微服务架构的话，我建议你和你的技术团队要将核心域的建设排在首
位，最好是有绝对的掌控能力和自主研发能力，如果资源实在有限的话，可以在支撑域或者通用域
上想想办法，暂时采用外购的方式也未尝不可。
6、思考题
请结合你所在公司的业务情况，尝试给业务做一个领域拆分，看看哪些子域是核心域，哪些子域是
通用域和支撑域？
7、通用语言
在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言
就是通用语言。
也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命
周期里都使用统一的语言进行交流。
通用语言的作用，它可以解决交流障碍这个问题，使领域专家和开发人员能够协同合作，从而确保
业务需求的正确表达。
从事件风暴建立，通用语言到领域对象设计和代码落地的完整过程。
1.在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会
形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程。
2.通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业
务对象和领域对象都有通用的名词术语，并且一一映射。
3.微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。
设计过程中我们可以用一些表格，来记录事件风暴和微服务设计过程中产生的领域对象及其属性。
比如，领域对象在DDD分层架构中的位置、属性、依赖关系以及与代码模型对象的映射关系等。
DDD分析和设计过程中的每一个环节都需要保证限界上下文内术语的统一，在代码模型设计的时
侯就要建立领域对象和代码对象的一一映射，从而保证业务模型和代码模型的一致，实现业务语言
与代码语言的统一。
8、限界上下文
DDD在战略设计上提出了“限界上下文”这个概念，用来确定语义所在的领域边界。
限界上下文的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些
术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不
应该在模型中实现。
限界上下文就是用来细分领域，从而定义通用语言所在的边界。
正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则
变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这
个边界就可能会成为未来微服务设计的边界。
领域边界就是通过限界上下文来定义的。
限界上下文和微服务的关系
每个领域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交流。领域内所有限界上
下文的领域模型构成整个领域的领域模型。
理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从
问题域到软件的解决方案。
可以说，限界上下文是微服务设计和拆分的主要依据。在领域模型中，如果不考虑技术异构、团队
沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
不过，这里还是要提示一下：除了理论，微服务的拆分还是有很多限制因素的，在设计中不宜过度
拆分。
9、总结
领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。
通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统
就是微服务了。
核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和
重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。
通用语言确定了项目团队内部交流的统一语言，而这个语言所在的语义环境则是由限界上下文来限
定的，以确保语义的唯一性。
限界上下文在微服务设计中的作用和意义是什么
而领域专家、架构师和开发人员的主要工作就是通过事件风暴来划分限界上下文。限界上下文确定
了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。如果不考虑技术异构、团队沟通等
其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
可以说，限界上下文在微服务设计中具有很重要的意义，如果限界上下文的方向偏离，那微服务的
设计结果也就可想而知了。因此，我们只有理解了限界上下文的真正涵义以及它在微服务设计中的
作用，才能真正发挥DDD的价值，这是基础也是前提。
限界上下文的作用是为了解决交流障碍。
通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内
都具有唯一的含义，领域模型则存在于这个边界之内。
这篇关于02.领域驱动设计：了解领域、子域、核心域、通用域、支撑域、通用语言和限界上下文的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
