你好，我是欧创新。今天我们重点学习“限界上下文”。
在DDD领域建模和系统建设过程中，有很多的参与者，包括领域专家、产品经理、项目经理、架构师、开发经理和测试经理等。对同样的领域知识，不同的参与角色可能会有不同的理解，那大家交流起来就会有障碍，怎么办呢？因此，在DDD中就出现了“通用语言”和“限界上下文”这两个重要的概念。
这两者相辅相成，通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。你是不是感觉这么描述很抽象？没关系，接下来我会给你一一详细讲解。
在这之前，我想请你先看这样两个问题，这也是今天内容的核心。
- 为什么要提出限界上下文的概念（也就是说除了解决交流障碍这个广义的原因，还有更具体的吗）？
- 限界上下文在微服务设计中的作用和意义是什么？
什么是通用语言？
为了更好地理解限界上下文，回答这两个问题，我们先从通用语言讲起。
怎么理解通用语言这个概念呢？在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流。
那么，通用语言的价值也就很明了了，它可以解决交流障碍这个问题，使领域专家和开发人员能够协同合作，从而确保业务需求的正确表达。
但是，对这个概念的理解，到这里还不够。
通用语言包含术语和用例场景，并且能够直接反映在代码中。通用语言中的名词可以给领域对象命名，如商品、订单等，对应实体对象；而动词则表示一个动作或事件，如商品已下单、订单已付款等，对应领域事件或者命令。
通用语言贯穿DDD的整个设计过程。作为项目团队沟通和协商形成的统一语言，基于它，你就能够开发出可读性更好的代码，将业务需求准确转化为代码设计。
下面我带你看一张图，这张图描述了从事件风暴建立通用语言到领域对象设计和代码落地的完整过程。
- 在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程。
- 通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射。
- 微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。
这里我再给你分享一条经验，我自己经常用，特别有效。设计过程中我们可以用一些表格，来记录事件风暴和微服务设计过程中产生的领域对象及其属性。比如，领域对象在DDD分层架构中的位置、属性、依赖关系以及与代码模型对象的映射关系等。
下面是一个微服务设计实例的部分数据，表格中的这些名词术语就是项目团队在事件风暴过程中达成一致、可用于团队内部交流的通用语言。在这个表格里面我们可以看到，DDD分析过程中所有的领域对象以及它们的属性都被记录下来了，除了DDD的领域对象，我们还记录了在微服务设计过程中领域对象所对应的代码对象，并将它们一一映射。
到这里，我要再强调一次。DDD分析和设计过程中的每一个环节都需要保证限界上下文内术语的统一，在代码模型设计的时侯就要建立领域对象和代码对象的一一映射，从而保证业务模型和代码模型的一致，实现业务语言与代码语言的统一。
如果你做到了这一点，也就是建立了领域对象和代码对象的映射关系，那就可以指导软件开发人员准确无误地按照设计文档完成微服务开发了。即使是不熟悉代码的业务人员，也可以很快找到代码的位置。
什么是限界上下文？
那刚刚提到的限界上下文又是用来做什么的呢？
我们知道语言都有它的语义环境，同样，通用语言也有它的上下文环境。为了避免同样的概念或语义在不同的上下文环境中产生歧义，DDD在战略设计上提出了“限界上下文”这个概念，用来确定语义所在的领域边界。
我们可以将限界上下文拆解为两个词：限界和上下文。限界就是领域的边界，而上下文则是语义环境。通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。
综合一下，我认为限界上下文的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。
进一步理解限界上下文
我们可以通过一些例子进一步理解一下这个概念，不要小看它，彻底弄懂会给你后面实践DDD打下一个坚实的基础。
都说中文这门语言非常丰富，在不同的时空和背景下，同样的一句话会有不同的涵义。有一个例子你应该听说过。
在一个明媚的早晨，孩子起床问妈妈：“今天应该穿几件衣服呀？”妈妈回答：“能穿多少就穿多少！”
那到底是穿多还是穿少呢？
如果没有具体的语义环境，还真不太好理解。但是，如果你已经知道了这句话的语义环境，比如是寒冬腊月或者是炎炎夏日，那理解这句话的涵义就会很容易了。
所以语言离不开它的语义环境。
而业务的通用语言就有它的业务边界，我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域。限界上下文就是用来细分领域，从而定义通用语言所在的边界。
现在我们用一个保险领域的例子来说明下术语的边界。保险业务领域有投保单、保单、批单、赔案等保险术语，它们分别应用于保险的不同业务流程。
- 客户投保时，业务人员记录投保信息，系统对应有投保单实体对象。
- 缴费完成后，业务人员将投保单转为保单，系统对应有保单实体对象，保单实体与投保单实体关联。
- 如客户需要修改保单信息，保单变为批单，系统对应有批单实体对象，批单实体与保单实体关联。
- 如果客户发生理赔，生成赔案，系统对应有报案实体对象，报案实体对象与保单或者批单实体关联。
投保单、保单、批单、赔案等，这些术语虽然都跟保单有关，但不能将保单这个术语作用在保险全业务领域。因为术语有它的边界，超出了边界理解上就会出现问题。
如果你对我从事的保险业不大了解也没关系，电商肯定再熟悉不过了吧？
正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。看到这，我想你应该非常清楚了，领域边界就是通过限界上下文来定义的。
限界上下文和微服务的关系
接下来，我们对这个概念做进一步的延伸。看看限界上下文和微服务具体存在怎样的关系。
我想你买过车险吧，或者听过吧。车险承保的流程包含了投保、缴费、出单等几个主要流程。如果出险了还会有报案、查勘、定损、理算等理赔流程。
保险领域还是很复杂的，在这里我用一个简化的保险模型来说明下限界上下文和微服务的关系。这里还会用到我们在 [第02讲] 学到一些基础知识，比如领域和子域。
首先，领域可以拆分为多个子领域。一个领域相当于一个问题域，领域拆分为子域的过程就是大问题拆分为小问题的过程。在这个图里面保险领域被拆分为：投保、支付、保单管理和理赔四个子域。
子域还可根据需要进一步拆分为子子域，比如，支付子域可继续拆分为收款和付款子子域。拆到一定程度后，有些子子域的领域边界就可能变成限界上下文的边界了。
子域可能会包含多个限界上下文，如理赔子域就包括报案、查勘和定损等多个限界上下文（限界上下文与理赔的子子域领域边界重合）。也有可能子域本身的边界就是限界上下文边界，如投保子域。
每个领域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交流。领域内所有限界上下文的领域模型构成整个领域的领域模型。
理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。
可以说，限界上下文是微服务设计和拆分的主要依据。在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
不过，这里还是要提示一下：除了理论，微服务的拆分还是有很多限制因素的，在设计中不宜过度拆分。那这个度怎么把握好呢？有关微服务设计和具体的拆分方法，我会在实战篇中详细讲解。
总结
通用语言确定了项目团队内部交流的统一语言，而这个语言所在的语义环境则是由限界上下文来限定的，以确保语义的唯一性。
而领域专家、架构师和开发人员的主要工作就是通过事件风暴来划分限界上下文。限界上下文确定了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
可以说，限界上下文在微服务设计中具有很重要的意义，如果限界上下文的方向偏离，那微服务的设计结果也就可想而知了。因此，我们只有理解了限界上下文的真正涵义以及它在微服务设计中的作用，才能真正发挥DDD的价值，这是基础也是前提。
思考题
现在，不妨回头看看，开头的两个问题你能回答了吗？你可以尝试用自己的话来总结一下。
最后再给你留一个作业，你能找一找自己工作中的通用语言和限界上下文吗？可以把你的答案和感受写下来，分享到留言区，与我一起讨论。也欢迎你把今天的内容分享给同事和朋友，邀请他一起学习。
精选留言
2019-10-20 06:49:26
英文是bounded context，应该叫上下文边界更合适。
2020-07-19 16:03:30
先说下背景，我的公司是做企业软件实施的，公司有技术中台、大数据中台、业务中台，我所在的技术中台是做通用框架平台的，主要是避免重复造轮子。基于 SpringCloud 开发了很多通用微服务和通用基础组件，比如网关服务、用户权限管理服务、认证服务、平台服务、消息服务、文件服务、支付服务、OCR服务、NLP服务、工作流服务等等。在给客户实施软件时，通过选配需要的服务即可搭建起一个基础平台，然后重点关注客户的核心业务服务开发。
首先关于核心域、通用域、支撑域的问题，像我所在技术中台这个领域内，我觉得所有的服务都属于我们的核心域，公司的战略就是成立技术中台来解决技术统一、通用能力沉淀、复用的问题，各个微服务其实没太多内在关联，都是通用微服务和组件。但要放到客户项目或者业务中台的产品，在他们的领域内，这些服务就变成了通用域或支撑域，而他们则把核心资源放到他们自身的业务上，那才是他们的核心域。这也应了文中说的商业模式的不同会导致核心域划分结果的不同。不知道这样理解有没有问题，主要是对技术中台这个领域的理解。
然后是我负责的用户权限管理服务，我觉得这个服务现在越来越重了，加的功能越来越多，也不太清楚如何划分这个领域，所以想请教下。我们最开始虽然采用了DDD的战术设计，但实际实施出来还是面向过程式的，以数据库驱动的方式来设计的。
主要的功能有：租户管理、用户管理、用户组管理、菜单管理、角色管理、客户端管理(OAuth2的客户端)、权限管理(API)
主要的动作有：
用户分配角色、用户分配工作台卡片
客户端分配角色
角色分配菜单权限、角色分配用户、角色分配客户端、角色分配数据权限、角色分配工作台卡片、角色分配字段权限、角色分配单据权限
角色创建又有复制、继承、直接创建三种创建方式
菜单下有创建目录、菜单、维护API权限等
其中工作台卡片、单据权限、数据权限是在平台服务进行数据维护的，平台服务和用户权限服务共用一个schema。
后面由于业务需求，又增加了安全组管理，相当于权限的集合，安全组分配菜单权限、数据权限、工作台卡片、字段权限、单据权限，然后角色增加了分配安全组的功能。
然后最近还增加了三员管理(保密系统的系统管理员、安全保密员、安全审计员)，不过这个是开发的一个服务插件，是可插拔的。
个人感觉整个用户权限服务越来越大、功能交错复杂，但又不好划分，而且由于代码层面各个功能耦合度较高，想拆分也比较难。
但说实在的，我们是做通用框架的，要满足各个项目的功能需求以及方便项目上定制化功能逻辑，个人觉得代码水平还可以，代码质量和扩展性上不是问题。但现在我想通过DDD的方式来试着重构这个服务，而且我们现在有些功能也正面临这拆分重组的问题。
这门课程我已经学完一遍了，如果按我的理解通过DDD的方式来重新拆分领域边界，将设计如下聚合：
租户聚合：
实体：租户
动作：创建租户
事件：租户初始化事件（租户初始化时会初始化其它的一些数据）
权限聚合：
实体：菜单、权限、用户、客户端、角色、租户
值对象：工作台卡片、字段权限、单据权限、数据权限，这些应该是通过远程服务获取的（那应该是DTO？还是建成值对象？）
动作：
菜单实体：菜单创建、目录创建、分配权限
权限实体：查询权限
用户实体：创建用户、修改密码
客户端实体：创建客户端
角色实体：创建角色、继承创建、复制创建
领域服务：
权限分配服务：分配角色菜单权限、分配角色卡片、分配角色字段权限、分配角色数据权限、分配角色单据权限、分配角色用户、分配角色客户端（我不是很确定是应该单独划分领域服务还是放到角色实体里面）
安全组聚合：
实体：安全组
值对象：菜单权限、卡片、字段权限、数据权限、单据权限、角色
领域服务：
安全组分配服务：处理角色和安全组的关系
应用服务：
安全组应用服务：通过服务编排，组合权限聚合中的权限分配领域服务，处理安全组下的菜单权限、卡片、数据权限等于角色的分配关系。
三员聚合：
实体：无
值对象：角色、菜单权限等
领域服务：三员角色领域服务
以上是我的个人理解，还望老师指点。我主要是想了解针对我们这种通用域类型的底层框架服务，好不好用DDD的战略和战术设计，又怎么划分边界，而且一定要满足功能的扩展，逻辑自定义。
2019-10-18 09:00:27
1这种查询你们会放在哪个微服务里做呢
2对于组合查询这种情况你们是连表查询，或者是不同服务通过id查询来提供属于它自己的那部分信息的，还是有更好的办法呢。
2019-10-22 21:56:50
往往对于很熟悉的领域比如您所处于的保险，或者电商，由于很熟悉，所以有些边界是一目了然的，比如销售上下文，库存上下文等。但是假设你处于一个完全陌生的领域，该怎样一步一步识别出这个上下文边界呢？
2020-04-07 19:09:01
1、领域对系统的一级划分，如果划分为领域已经可以进行事件风暴，则没有必要再拆分为子域，直接在领域内进行事件风暴。
2、子域是个相对概念，在一个大系统里的子域可能比一个小系统的领域还要大，比如有两个平台，一个平台是京东级的电商平台，一个是小图书馆的管理系统，电商平台的用户子域，比图书管理系统的用户领域要大的多。对小系统而言，可能没有子域的概念，系统划分领域后，直接在领域上进行事件风暴。
3、界限上下文与领域、子域最大的区别是，上下文是在事件风暴后产生的，事件风暴后产生的上下文可能反过来会影响子域的划分。
4、界限上下文一直是理解的难点，一个动作是一个界限上下文？比如用户登录；还是一个名词是一个界限上下文？比如用户。我的理解是一个界限上下文是都可以，界限上下文最大的作用是限定哪些名词和动作是在这个界限内的，比如用户管理可以做为一个界限上下文（子域），用户登录和注册就在这个上下文内，设备的管理就不在这个上下文内，所以就不属于这个上下文（子域），代码实现的时候，设备相关的操作就不应该在用户管理服务里实现。
2019-10-22 09:28:14
2020-10-22 19:14:51
2019-10-18 12:01:52
2019-10-18 08:37:15
1、主要是为了消除通用语言在不同领域中的歧义或者说是限制通用语言的使用范围。
2、是划分领域的重要依据
3、通用语言必须与限界上下文配合使用才有意义
二、限界上下文可以作为微服务拆分的重要依据
2019-10-21 16:13:50
2019-10-21 15:44:20
软件就是在表达这个世界的人和人的关系，人和物的关系，物和物之间的关系。他们之间的关系要么是从属，要么是分类。
在我之前的一个项目中，就遇到了这个给问题，他是一个人的对象，按照从属关系，他属于其中一个微服务，可是在实际操作中，发现它和我们的用户权限微服务关系更紧密。
没办法，只好把他从业务的微服务中移到用户权限的微服务中去了。
我想问问，在领域和子域的划分中，有没有非常明确的方法论没有。
我相信在业务的讨论中，不同人，从不同的角度看，我相信会有不同的划分区别。
2019-10-18 20:26:32
1。限界上下文是通过细化到最后的子域的边界来决定的吗？
2。这些边界怎么组成一个完整的限界上下文呢()可以通过微服务落地的)？
3。软件是变化的，那限界上下文是不是也是会变化的呢？比如会根据这个变化来进行微服务拆分？
现在有n个微服务，除了组织架构这种支撑服务，其他的没法确定边界
2020-06-04 15:43:26
2020-02-21 12:20:57
2020-02-02 10:17:58
2019-10-22 11:02:51
2019-10-22 09:39:48
拆到一定程度后，有些子子域的领域边界就可能变成限界上下文的边界了。
请问，怎样理解“一定程度”呢？
“子子域的领域边界可能变成限界上下文的边界”，这句也不太好把握？
2019-10-21 07:50:17
2020-06-04 16:31:27
举个简单的例子，希望老师稍微指导一下，谢谢。
我们是做个信息对接平台的和58类似。用户分为 招聘方和求职方，招聘方发布招聘信息，求职方查看招聘信息。
求职方查看信息需要消耗积分，积分是通过充值或者拉新换来的(主要还是充值)。积分消耗主要是查看信息；以及置顶自己的信息。
招聘信息由招聘方发布，还有一部分是公司通过其他渠道获取的。
我做了个划分：
用户模块： 登录、注册 ....
信息模块： 招聘方发布、其他渠道获取 ，信息各种操作 ...
积分模块： 积分来源以及消耗记录，充值单价的设定 ...
这里我的疑问是，消耗、和获的 积分这个操作是放到 积分模块 还是用户模块。
如果 放到积分模块，需要修改用户剩余积分。
如果 放到用户模块，需要增加一条积分记录。
2020-04-23 08:20:40