03 | 限界上下文：定义领域边界的利器
该思维导图由 AI 生成，仅供参考
什么是通用语言？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
限界上下文是领域驱动设计（DDD）中的重要概念，用于定义领域边界和统一通用语言的上下文环境。通用语言和限界上下文相辅相成，通用语言解决了交流障碍，而限界上下文则确定了语义所在的领域边界。通过例子，文章进一步解释了限界上下文的重要性和应用。保险业务领域中的投保单、保单、批单、赔案等术语，以及电商领域中的商品和货物，展示了术语在不同领域边界内的不同涵义和职责边界。限界上下文在微服务设计中具有重要意义，确定了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。通过事件风暴建立通用语言，团队能够形成统一的业务术语和用户故事，进而将业务需求准确转化为代码设计。限界上下文在微服务设计中具有很重要的意义，如果限界上下文的方向偏离，那微服务的设计结果也就可想而知了。
《DDD 实战课》，新⼈⾸单¥59
全部留言(129)
- 最新
- 精选
蚂蚁内推+v限界上下文大概是直译过来的一个晦涩的术语，理解成本较高。 英文是bounded context，应该叫上下文边界更合适。作者回复: 是的，赞一个。
2019-10-207117
Lambor老师您好，关于领域划分想咨询下。 先说下背景，我的公司是做企业软件实施的，公司有技术中台、大数据中台、业务中台，我所在的技术中台是做通用框架平台的，主要是避免重复造轮子。基于 SpringCloud 开发了很多通用微服务和通用基础组件，比如网关服务、用户权限管理服务、认证服务、平台服务、消息服务、文件服务、支付服务、OCR服务、NLP服务、工作流服务等等。在给客户实施软件时，通过选配需要的服务即可搭建起一个基础平台，然后重点关注客户的核心业务服务开发。 首先关于核心域、通用域、支撑域的问题，像我所在技术中台这个领域内，我觉得所有的服务都属于我们的核心域，公司的战略就是成立技术中台来解决技术统一、通用能力沉淀、复用的问题，各个微服务其实没太多内在关联，都是通用微服务和组件。但要放到客户项目或者业务中台的产品，在他们的领域内，这些服务就变成了通用域或支撑域，而他们则把核心资源放到他们自身的业务上，那才是他们的核心域。这也应了文中说的商业模式的不同会导致核心域划分结果的不同。不知道这样理解有没有问题，主要是对技术中台这个领域的理解。 然后是我负责的用户权限管理服务，我觉得这个服务现在越来越重了，加的功能越来越多，也不太清楚如何划分这个领域，所以想请教下。我们最开始虽然采用了DDD的战术设计，但实际实施出来还是面向过程式的，以数据库驱动的方式来设计的。 主要的功能有：租户管理、用户管理、用户组管理、菜单管理、角色管理、客户端管理(OAuth2的客户端)、权限管理(API) 主要的动作有： 用户分配角色、用户分配工作台卡片 客户端分配角色 角色分配菜单权限、角色分配用户、角色分配客户端、角色分配数据权限、角色分配工作台卡片、角色分配字段权限、角色分配单据权限 角色创建又有复制、继承、直接创建三种创建方式 菜单下有创建目录、菜单、维护API权限等 其中工作台卡片、单据权限、数据权限是在平台服务进行数据维护的，平台服务和用户权限服务共用一个schema。 后面由于业务需求，又增加了安全组管理，相当于权限的集合，安全组分配菜单权限、数据权限、工作台卡片、字段权限、单据权限，然后角色增加了分配安全组的功能。 然后最近还增加了三员管理(保密系统的系统管理员、安全保密员、安全审计员)，不过这个是开发的一个服务插件，是可插拔的。 个人感觉整个用户权限服务越来越大、功能交错复杂，但又不好划分，而且由于代码层面各个功能耦合度较高，想拆分也比较难。 但说实在的，我们是做通用框架的，要满足各个项目的功能需求以及方便项目上定制化功能逻辑，个人觉得代码水平还可以，代码质量和扩展性上不是问题。但现在我想通过DDD的方式来试着重构这个服务，而且我们现在有些功能也正面临这拆分重组的问题。 这门课程我已经学完一遍了，如果按我的理解通过DDD的方式来重新拆分领域边界，将设计如下聚合： 租户聚合： 实体：租户 动作：创建租户 事件：租户初始化事件（租户初始化时会初始化其它的一些数据） 权限聚合： 实体：菜单、权限、用户、客户端、角色、租户 值对象：工作台卡片、字段权限、单据权限、数据权限，这些应该是通过远程服务获取的（那应该是DTO？还是建成值对象？） 动作： 菜单实体：菜单创建、目录创建、分配权限 权限实体：查询权限 用户实体：创建用户、修改密码 客户端实体：创建客户端 角色实体：创建角色、继承创建、复制创建 领域服务： 权限分配服务：分配角色菜单权限、分配角色卡片、分配角色字段权限、分配角色数据权限、分配角色单据权限、分配角色用户、分配角色客户端（我不是很确定是应该单独划分领域服务还是放到角色实体里面） 安全组聚合： 实体：安全组 值对象：菜单权限、卡片、字段权限、数据权限、单据权限、角色 领域服务： 安全组分配服务：处理角色和安全组的关系 应用服务： 安全组应用服务：通过服务编排，组合权限聚合中的权限分配领域服务，处理安全组下的菜单权限、卡片、数据权限等于角色的分配关系。 三员聚合： 实体：无 值对象：角色、菜单权限等 领域服务：三员角色领域服务 以上是我的个人理解，还望老师指点。我主要是想了解针对我们这种通用域类型的底层框架服务，好不好用DDD的战略和战术设计，又怎么划分边界，而且一定要满足功能的扩展，逻辑自定义。作者回复: 内容比较多，不知道理解的对不对？不对的地方请指出。 在设计的时候要考虑聚合的职责单一原则。我大概梳理一下，这里面有些功能是基础数据管理和配置，如用户、租户、菜单、角色配置等，有些是多个聚合数据组合后形成的聚合，比如用户权限聚合。 第一、要完成权限管理功能会有用户或者租户。这些数据都是非常基础的实体，完成用户和租户基础数据管理，因此会有用户或租户聚合，聚合根分别是用户和租户。 用户和租户这一块应该在一个限界上下文内。 第二、系统中会有菜单等基础数据配置，因此会有菜单管理相关的聚合，聚合根是菜单。 第三、在进行权限设置时，首先需要定义角色（角色是不是岗位的意思？），角色定义完成后实际上是一种通用静态配置数据吧，角色关联菜单（一对多），字段，数据以及单据等实体，因此会有角色（岗位）聚合。但需要注意：如果不同用户角色的菜单权限一样，但是数据权限或者单据权限不同，这样设计就可能不合适，这时数据权限和单据权限就不能关联到角色了。这里不清楚你说的数据权限和单据权限是否需要单独维护和管理，如果需要独立维护就可以独立为数据和单据权限等的基础数据配置的聚合。 第四、菜单权限、卡片、字段权限、数据权限、单据权限、角色等多个值对象权限组合为一个安全组，形成安全组聚合。 第五、用户（租户）与角色或安全组权限结合一起形成用户（租户）权限，因此会有用户权限聚合，用户权限是聚合根，它会关联安全组或用户、角色、数据等其他聚合的数据，用户、角色、数据以值对象的形式被用户权限聚合根引用。 三员管理我理解也应该是角色相关的管理。 第二到第五的内容应该在一个权限相关的限界上下文内。 第六、考虑到登录，应该还有账户聚合，账户是聚合根，完成密码和登录管理，另外账户会引用用户值对象。这些内容在一个限界上下文内。 完成这些聚合设计后，聚合之间的协调可以通过应用服务来实现。
2020-07-194471
LY老师，我有一个问题，对于你们保险行业来说，投保单、保单、批单、赔案，这些领悟概念都是在不同的限界上下文中，那么就是在不同的微服务中，拆分开以后，如果管理后台有一个需求，需要查出一个列表，列表的字段信息需要这些所有不同类型的订单的组合。 1这种查询你们会放在哪个微服务里做呢 2对于组合查询这种情况你们是连表查询，或者是不同服务通过id查询来提供属于它自己的那部分信息的，还是有更好的办法呢。作者回复: 这种跨多个微服务的数据查询。对于准实时的查询，你可以考虑数据中台。在数据中台会归拢所有的微服务的数据，在数据中台提供统一的各个维度数据的集中查询。对于实时性要求高的，你可以考虑一定的数据冗余，上游的业务数据做完后，实时写入到需要联表查询的库中，写入时只写入必要的数据就可以了。
2019-10-181170
stg609谢谢老师的文章，很受用。我们公司也在实践DDD, 但是遇到很多问题。其中之一就是不能合理的定义这个BC。能不能具体说下如何去划分这个限界上下文？或者说根据什么去判断边界在哪？ 往往对于很熟悉的领域比如您所处于的保险，或者电商，由于很熟悉，所以有些边界是一目了然的，比如销售上下文，库存上下文等。但是假设你处于一个完全陌生的领域，该怎样一步一步识别出这个上下文边界呢？作者回复: 限界上下文划分主要依据是业务的语义边界，比如客户的环境下只说客户相关的事情，权限环境下只定义权限相关的业务逻辑。对于陌生业务环境，经过分析，你基本能够知道有哪些流程和场景，这些流程和场景里应该有对应的语义环境。 而在具体的分析过程中，在确定一个子域，并完成事件风暴后，你可以找出实体和聚合，实体和聚合根他们有业务属性和逻辑。你基本知道这个聚合可以作什么样的业务，如果多个聚合共同完整这类业务，你就可以把多个聚合放在一个限界上下文内，这样一个限界上下文就形成了。
2019-10-22248
新新已经是第三遍刷了，第一遍只记住了DDD是微服务拆分的利器，第二遍记住了领域、子域、界限上下文、聚合等这些概念，第三遍有了一些自己的理解，对应领域、子域、界限上下文我是这样理解的： 1、领域对系统的一级划分，如果划分为领域已经可以进行事件风暴，则没有必要再拆分为子域，直接在领域内进行事件风暴。 2、子域是个相对概念，在一个大系统里的子域可能比一个小系统的领域还要大，比如有两个平台，一个平台是京东级的电商平台，一个是小图书馆的管理系统，电商平台的用户子域，比图书管理系统的用户领域要大的多。对小系统而言，可能没有子域的概念，系统划分领域后，直接在领域上进行事件风暴。 3、界限上下文与领域、子域最大的区别是，上下文是在事件风暴后产生的，事件风暴后产生的上下文可能反过来会影响子域的划分。 4、界限上下文一直是理解的难点，一个动作是一个界限上下文？比如用户登录；还是一个名词是一个界限上下文？比如用户。我的理解是一个界限上下文是都可以，界限上下文最大的作用是限定哪些名词和动作是在这个界限内的，比如用户管理可以做为一个界限上下文（子域），用户登录和注册就在这个上下文内，设备的管理就不在这个上下文内，所以就不属于这个上下文（子域），代码实现的时候，设备相关的操作就不应该在用户管理服务里实现。作者回复: 多看几遍理解就是不一样啊。
2020-04-07325
朱振光从事件风暴到代码落地的5个步骤中，并没有提到子域划分和bounded context的划分，这个两个步骤应该在哪一步进行呢？bounded context划分是直接基于子域里面划分，还是在整个领域内划分，最后再和子域mapping？作者回复: 做子域划分的主要目的就是把问题域细分，然后你才能做事件风暴，子域太大你hold不住！这些细分的子域是相对较大的领域，在事件风暴之前先做子域细分。子域细分后，你就可以在子域内用事件风暴建立领域模型，建模过程中会对聚合进行归类，形成限界上下文边界。这个限界上下文，其实你也可以认为是一个子域。
2019-10-22224
信了子域和限界上下文是什么关系？是包含吗作者回复: 我把书里面的内容直接贴过来吧。 学完第 5 章和本章后，有人可能会对子域与限界上下文的关系有些困惑。子域和限界上下文的映射关系到底是什么样的？一对多？或者多对一？还是一对一？ 其实，在 DDD 中包括问题域和解决方案域两个不同的维度。问题域主要从业务视角来考虑，完成从领域到子域的分解，而解决方案域则主要从技术实现的角度，通过划分限界上下文和采用 DDD 战术设计完成微服务的拆分和落地。“子域”和“限界上下文”这两个概念分别从不同的视角，构建起了 DDD 处理业务复杂度的根基。 个人认为“子域”和“限界上下文”在大多数情况下是一对一或者一对多的映射关系。从实践角度可以这样理解，我们不妨将业务领域的分解拆分为两个阶段：从领域到子域的粗粒度的分解和从子域到限界上下文的技术实现级的分解。有时候企业的业务领域非常庞大，不太方便用事件风暴对整个领域构建领域模型。所以在领域建模之前，我们先根据业务流程边界或者功能集合等要素，将庞大的领域分解成若干个大小合适的子域，然后根据子域属性划分为核心子域、通用子域和支撑子域。当领域分解到足够小后，我们就可以在这些子域内开展事件风暴，划分限界上下文完成领域建模了。 在对不同属性子域构建领域模型时，我们可能会有不同的关注点，比如在通用子域构建领域模型时，我们会更多关注领域模型的抽象和标准化，以便实现企业级复用，这种设计方法与中台的业务建模思想是一致的。当然，如果你的领域足够小的话，我们就没必要进行从领域到子域的分解和属性归类了，你可以直接开展事件风暴，直接划分限界上下文，完成领域建模。按照这种分解方式，如果子域和限界上下文边界刚好一致，那它们就是一对一的关系，而如果在一个子域内还可以划分为多个限界上下文，那我们最终得到的就是一对多的映射关系。需要注意的是，有些通用子域构建出来的领域模型往往会因为需要复用，可能会跨多个不同的业务子域，组合以后形成企业级能力。 限界上下文本质上就是子域，只不过它会更多地考虑领域对象的语义边界和技术实现细节。限界上下文的划分体现的是一种更为详细的设计过程，这个过程划分了业务的上下文语义边界，完成了领域模型，明确了领域对象以及领域对象之间的依赖关系等。至此， 我们依据限界上下文和领域模型就可以完成微服务设计和落地了。
2020-10-22314
TH以前基于模块的编程方式，会将不同业务中属于同一个对象的功能都写到这个对象的类中，导致这个类非常庞大，从逻辑上来说也将复杂的业务耦合到了一起。如果使用DDD的方式来设计系统，比如文中所举的保单的例子，应该不同的业务线或者说不同的限界上下文内都应当实现自己的保单对象，对应到微服务就是以限界上下文来划分服务，而不是以对象或功能集来划分服务，因此不存在一个单独的“保单”服务，是这样的吗？作者回复: 不同产品线如果领域模型差异太大的话，建议还是分开建设。这样不同产品之间的影响就很小了，也减少了很多兼容带来的开销，用户体验也不会太好。所以可以针对不同场景的产品设计出不同的微服务，但是在前端设计的时候需要注意，这些不同类产品的业务流程和前端界面是可以很好的融合在一起的。前端的设计我在后面也会有一节来讲解。注意一下，业务差异不是太大，不会带来太大复杂度的话，还是尽量建立一个领域模型。
2019-10-18513
波波一、限界上下文的作用 1、主要是为了消除通用语言在不同领域中的歧义或者说是限制通用语言的使用范围。 2、是划分领域的重要依据 3、通用语言必须与限界上下文配合使用才有意义 二、限界上下文可以作为微服务拆分的重要依据作者回复: 是的。
2019-10-1811- WING欧老师，文中提到“理赔子域就包括报案、查勘和定损等多个界限上下文(界限上下文与理赔的子子域边界重合)”这句话边界重合怎么理解?是否理赔应该作为一个微服务?另外，如果理赔流程在技术上引入了工作流引擎(如flowable)，那么这个工作流引擎又处于什么位置？
作者回复: 理赔相对保险领域来说是一个比较大的子域。由于子域过大不太容易做事件风暴，因此还需要继续细分子域。当子域细分到一定程度后，对这个子域的分析就比较容易了，很有可能这个子域就是一个限界上下文，所以这时候子子域的边界与限界上下文的边界是一致的。理赔不是一个微服务，需要根据不同子域事件风暴建立领域模型后，它其中的某个业务子域就是一个微服务，比如报案之类的。你说的这个工作流引擎是不是跨了很多的微服务，如果做统一协调，按照职能划分它应该是一个工作流微服务。另外，我简单分析一下，有的时候DDD的事件驱动可以替代工作流的功能，通过事件驱动推动业务在不同的领域模型中的流转。后面的章节会讲到。
2019-10-21410
