03 | 限界上下文：定义领域边界的利器
什么是通用语言？
请订阅文章所属专栏。
精选留言(53)
小美限界上下文大概是直译过来的一个晦涩的术语，理解成本较高。
英文是bounded context，应该叫上下文边界更合适。作者回复: 是的，赞一个。
2019-10-20 1 15
碧落惊鸿LY老师，我有一个问题，对于你们保险行业来说，投保单、保单、批单、赔案，这些领悟概念都是在不同的限界上下文中，那么就是在不同的微服务中，拆分开以后，如果管理后台有一个需求，需要查出一个列表，列表的字段信息需要这些所有不同类型的订单的组合。
1这种查询你们会放在哪个微服务里做呢
2对于组合查询这种情况你们是连表查询，或者是不同服务通过id查询来提供属于它自己的那部分信息的，还是有更好的办法呢。作者回复: 这种跨多个微服务的数据查询。对于准实时的查询，你可以考虑数据中台。在数据中台会归拢所有的微服务的数据，在数据中台提供统一的各个维度数据的集中查询。对于实时性要求高的，你可以考虑一定的数据冗余，上游的业务数据做完后，实时写入到需要联表查询的库中，写入时只写入必要的数据就可以了。
2019-10-18 4 11
TH以前基于模块的编程方式，会将不同业务中属于同一个对象的功能都写到这个对象的类中，导致这个类非常庞大，从逻辑上来说也将复杂的业务耦合到了一起。如果使用DDD的方式来设计系统，比如文中所举的保单的例子，应该不同的业务线或者说不同的限界上下文内都应当实现自己的保单对象，对应到微服务就是以限界上下文来划分服务，而不是以对象或功能集来划分服务，因此不存在一个单独的“保单”服务，是这样的吗？作者回复: 不同产品线如果领域模型差异太大的话，建议还是分开建设。这样不同产品之间的影响就很小了，也减少了很多兼容带来的开销，用户体验也不会太好。所以可以针对不同场景的产品设计出不同的微服务，但是在前端设计的时候需要注意，这些不同类产品的业务流程和前端界面是可以很好的融合在一起的。前端的设计我在后面也会有一节来讲解。注意一下，业务差异不是太大，不会带来太大复杂度的话，还是尽量建立一个领域模型。
2019-10-18 2 7
朱振光从事件风暴到代码落地的5个步骤中，并没有提到子域划分和bounded context的划分，这个两个步骤应该在哪一步进行呢？bounded context划分是直接基于子域里面划分，还是在整个领域内划分，最后再和子域mapping？作者回复: 做子域划分的主要目的就是把问题域细分，然后你才能做事件风暴，子域太大你hold不住！这些细分的子域是相对较大的领域，在事件风暴之前先做子域细分。子域细分后，你就可以在子域内用事件风暴建立领域模型，建模过程中会对聚合进行归类，形成限界上下文边界。这个限界上下文，其实你也可以认为是一个子域。
2019-10-22 1 3
波波一、限界上下文的作用
1、主要是为了消除通用语言在不同领域中的歧义或者说是限制通用语言的使用范围。
2、是划分领域的重要依据
3、通用语言必须与限界上下文配合使用才有意义
二、限界上下文可以作为微服务拆分的重要依据作者回复: 是的。
2019-10-18 3
stg609谢谢老师的文章，很受用。我们公司也在实践DDD, 但是遇到很多问题。其中之一就是不能合理的定义这个BC。能不能具体说下如何去划分这个限界上下文？或者说根据什么去判断边界在哪？
往往对于很熟悉的领域比如您所处于的保险，或者电商，由于很熟悉，所以有些边界是一目了然的，比如销售上下文，库存上下文等。但是假设你处于一个完全陌生的领域，该怎样一步一步识别出这个上下文边界呢？作者回复: 限界上下文划分主要依据是业务的语义边界，比如客户的环境下只说客户相关的事情，权限环境下只定义权限相关的业务逻辑。对于陌生业务环境，经过分析，你基本能够知道有哪些流程和场景，这些流程和场景里应该有对应的语义环境。
而在具体的分析过程中，在确定一个子域，并完成事件风暴后，你可以找出实体和聚合，实体和聚合根他们有业务属性和逻辑。你基本知道这个聚合可以作什么样的业务，如果多个聚合共同完整这类业务，你就可以把多个聚合放在一个限界上下文内，这样一个限界上下文就形成了。2019-10-22 2
sqyao请问欧老师，事件风暴指的是什么？作者回复: 事件风暴跟头脑风暴类似，项目团队跟领域专家一起，尽可能全面的根据领域事件梳理业务的各种可能，找出产生这些事件的实体，进行聚合，划分限界上下文建立领域模型的过程。后面会有专门一章来讲解如何做事件风暴，请耐心等待。
2019-10-20 1 2
陈华应老师，一直以为是先从业务来确定限界上下文，看完这篇有点疑惑，
1。限界上下文是通过细化到最后的子域的边界来决定的吗？
2。这些边界怎么组成一个完整的限界上下文呢()可以通过微服务落地的)？
3。软件是变化的，那限界上下文是不是也是会变化的呢？比如会根据这个变化来进行微服务拆分？
现在有n个微服务，除了组织架构这种支撑服务，其他的没法确定边界作者回复: 限界上下文是从业务端分析得出的。由于一般的领域过大，不太好下手去做事件风暴，所以在划分到合适的子域后做事件风暴就没那么复杂了。限界上下文是由若干个聚合构成的，聚合具有一定的业务内聚性。在依据限界上下文完成微服务设计后，以后还是可以很容易根据领域模型的变化来演进的。微服务演进过程主要是微服务之间聚合的重构。所以设计时要做好聚合的代码边界。
2019-10-18 2- 云之子你好，我是否可以理解为领域>=子域>=界限上下文。比如一般一些简单的系统，可能就分为一个前台面对用户，一个后台面对内部的管理后台，那么是不是先把这两个系统分成两个领域，然后去细化里面的实体，将实体进行聚合，确定限界上下文，有可能限界上下文就是领域。
如果通过聚合发现要拆分限界上下文，就需要拆分项目。
另外，比如一个小系统分为账号、公告、厂商管理、厂商信息管理这几块，那么是否可以把他们归为一个限界上下文，还是要把账号、公告、厂商分为3个作者回复: 不清楚你说的前台是否包含业务逻辑还是只是前端页面。如果包含了丰富做的业务逻辑，前后台可以分开做领域模型。
小系统，如果逻辑不复杂的话，个人不建议过多的拆分微服务。你说的这几个模型块可以形成聚合。以后可根据需要再拆分为微服务。2019-11-13 1 - stg609另外文中提到理赔子域包含多个上下文，那为什么不再把理赔子域进一步进行拆分呢？做到子域和上下文一一对应？
作者回复: 子域的划分是一个业务粗分过程。而限界上下文这个设计过程是一个详细的领域建模和微服务设计过程。
如果领域太大，你不方便进行分析和设计。子域划分的主要目的就是为了将领域的问题空间缩小，以方便你下一步进行详细的领域建模和微服务设计，而这个过程是一个非常细致的过程。限界上下文实际上也是一种分析后得出的子域。
所以有了这两个阶段。2019-10-22 1 
观海雲遠你好,老师。 其实我很想知道当各个子域都确认了之后, 研发如何入手，从哪儿开始呢？ 如何与敏捷中的故事卡结合。希望能有这方面的解答。 谢谢老师作者回复: 确定子域后，就可以做事件风暴了。事件风暴是一个领域建模的过程，实际上有一部分的工作是做用例分析，尽量全面的梳理业务的各种领域事件，找出实体、聚合等，根据业务语义划定限界上下文，建立领域模型，限界上下文是业务边界，也是微服务设计的边界。从领域模型到微服务还会有一个分析的过程。
微服务设计完成后，后面的开发方式就没什么区别了。2019-10-22 2 1
嘉嘉☕老师好
拆到一定程度后，有些子子域的领域边界就可能变成限界上下文的边界了。
请问，怎样理解“一定程度”呢？
“子子域的领域边界可能变成限界上下文的边界”，这句也不太好把握？作者回复: 你可以把限界上下文理解成一个子域。
限界上下文是在事件风暴后产生的，在找出实体和聚合后，会将聚合归拢到限界上下文，让他们在同一个业务语义环境下工作。这样多个聚合一起就组成了限界上下文，完成特定的业务领域的功能，这个限界上下文是不是就是一个子域呢？2019-10-22 1- WING欧老师，文中提到“理赔子域就包括报案、查勘和定损等多个界限上下文(界限上下文与理赔的子子域边界重合)”这句话边界重合怎么理解?是否理赔应该作为一个微服务?另外，如果理赔流程在技术上引入了工作流引擎(如flowable)，那么这个工作流引擎又处于什么位置？
作者回复: 理赔相对保险领域来说是一个比较大的子域。由于子域过大不太容易做事件风暴，因此还需要继续细分子域。当子域细分到一定程度后，对这个子域的分析就比较容易了，很有可能这个子域就是一个限界上下文，所以这时候子子域的边界与限界上下文的边界是一致的。理赔不是一个微服务，需要根据不同子域事件风暴建立领域模型后，它其中的某个业务子域就是一个微服务，比如报案之类的。你说的这个工作流引擎是不是跨了很多的微服务，如果做统一协调，按照职能划分它应该是一个工作流微服务。另外，我简单分析一下，有的时候DDD的事件驱动可以替代工作流的功能，通过事件驱动推动业务在不同的领域模型中的流转。后面的章节会讲到。
2019-10-21 1 1 - 瓜瓜我在拆分微服务的时候，一般是按照从属关系来划分的。
软件就是在表达这个世界的人和人的关系，人和物的关系，物和物之间的关系。他们之间的关系要么是从属，要么是分类。
在我之前的一个项目中，就遇到了这个给问题，他是一个人的对象，按照从属关系，他属于其中一个微服务，可是在实际操作中，发现它和我们的用户权限微服务关系更紧密。
没办法，只好把他从业务的微服务中移到用户权限的微服务中去了。
我想问问，在领域和子域的划分中，有没有非常明确的方法论没有。
我相信在业务的讨论中，不同人，从不同的角度看，我相信会有不同的划分区别。作者回复: 就我了解来说还没有量化的划分方法。主要依赖项目团队和领域专家的判断。
在事件风暴时候，子域不能太大，要不你hold不住。其实你说的那个人的问题，做微服务设计时会有一些技巧的，尤其是分布式架构下。如果一个对象同时存在于两个微服务中，你可以考虑一定的数据冗余。其中的一个微服务这个对象是主要的业务环节，它可以被设计为实体，而在另外一个微服务中这个数据是冗余数据，它可以设计为值对象或者关联实体。2019-10-21 1 
TwoPunchMan老师讲的很详细,不过建议老师专有名词可以在旁边放入原英文对照, 这样我们要多了解可以直接搜寻国外更多资料作者回复: 好的，下次注意一下。
2019-10-19 1
m5jun文章有个地方说的有问题，领域模型和代码模型肯定不是一一对应的吧？作者回复: 用事件风暴建立领域模型后，我们还会进一步分析，确定更细的实体和值对象，以及各层的服务，这些都是领域对象。然后这些领域对象会跟代码模型中的数据实体，服务等代码对象建立映射关系。这个分析过程与传统的研发模式不太一样。
2019-10-18 3 1
刘哲老师，我觉得你上图把，领域和方法都写在一起，不如把领域的聚合根、实体、值对象单独写，方法是要做软件工期控制的，应该另写，这样更加条理分明作者回复: 主要目的是把对象和行为放一起，面向对象嘛。DDD强调对象和它的行为。
2019-12-11- 刘哲老师，领域对象和代码对象映射图，我看到有点费解，领域对象不是只包含：聚合根、值对象、实体这三个属性么，怎么会有领域服务、命令、事件发布等属性？
作者回复: 你可以把范围扩大一点，就是领域模型中的对象，表格主要是为了记录这些对象。聚合根和实体属于实体对象。
2019-12-11 
zj第二遍看了，现在总结一下：领域经过细分成子域或者子子域后，那这个子域或者子子域可能就是限界上下文。作者回复: 第二遍的感觉跟第一遍相比，是否理解的更透彻一些了呢？
2019-11-24 1
krugle表格中的应用层怎么理解作者回复: 它是DDD分层架构中的一层，建议你看一下第7节的DDD分层架构。
2019-11-22