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