作者回复: 是的,赞一个。
作者回复: 这种跨多个微服务的数据查询。对于准实时的查询,你可以考虑数据中台。在数据中台会归拢所有的微服务的数据,在数据中台提供统一的各个维度数据的集中查询。对于实时性要求高的,你可以考虑一定的数据冗余,上游的业务数据做完后,实时写入到需要联表查询的库中,写入时只写入必要的数据就可以了。
作者回复: 不同产品线如果领域模型差异太大的话,建议还是分开建设。这样不同产品之间的影响就很小了,也减少了很多兼容带来的开销,用户体验也不会太好。所以可以针对不同场景的产品设计出不同的微服务,但是在前端设计的时候需要注意,这些不同类产品的业务流程和前端界面是可以很好的融合在一起的。前端的设计我在后面也会有一节来讲解。注意一下,业务差异不是太大,不会带来太大复杂度的话,还是尽量建立一个领域模型。
作者回复: 做子域划分的主要目的就是把问题域细分,然后你才能做事件风暴,子域太大你hold不住!这些细分的子域是相对较大的领域,在事件风暴之前先做子域细分。子域细分后,你就可以在子域内用事件风暴建立领域模型,建模过程中会对聚合进行归类,形成限界上下文边界。这个限界上下文,其实你也可以认为是一个子域。
作者回复: 是的。
作者回复: 限界上下文划分主要依据是业务的语义边界,比如客户的环境下只说客户相关的事情,权限环境下只定义权限相关的业务逻辑。对于陌生业务环境,经过分析,你基本能够知道有哪些流程和场景,这些流程和场景里应该有对应的语义环境。
而在具体的分析过程中,在确定一个子域,并完成事件风暴后,你可以找出实体和聚合,实体和聚合根他们有业务属性和逻辑。你基本知道这个聚合可以作什么样的业务,如果多个聚合共同完整这类业务,你就可以把多个聚合放在一个限界上下文内,这样一个限界上下文就形成了。
作者回复: 事件风暴跟头脑风暴类似,项目团队跟领域专家一起,尽可能全面的根据领域事件梳理业务的各种可能,找出产生这些事件的实体,进行聚合,划分限界上下文建立领域模型的过程。后面会有专门一章来讲解如何做事件风暴,请耐心等待。
作者回复: 限界上下文是从业务端分析得出的。由于一般的领域过大,不太好下手去做事件风暴,所以在划分到合适的子域后做事件风暴就没那么复杂了。限界上下文是由若干个聚合构成的,聚合具有一定的业务内聚性。在依据限界上下文完成微服务设计后,以后还是可以很容易根据领域模型的变化来演进的。微服务演进过程主要是微服务之间聚合的重构。所以设计时要做好聚合的代码边界。
作者回复: 不清楚你说的前台是否包含业务逻辑还是只是前端页面。如果包含了丰富做的业务逻辑,前后台可以分开做领域模型。
小系统,如果逻辑不复杂的话,个人不建议过多的拆分微服务。你说的这几个模型块可以形成聚合。以后可根据需要再拆分为微服务。
作者回复: 子域的划分是一个业务粗分过程。而限界上下文这个设计过程是一个详细的领域建模和微服务设计过程。
如果领域太大,你不方便进行分析和设计。子域划分的主要目的就是为了将领域的问题空间缩小,以方便你下一步进行详细的领域建模和微服务设计,而这个过程是一个非常细致的过程。限界上下文实际上也是一种分析后得出的子域。
所以有了这两个阶段。
作者回复: 确定子域后,就可以做事件风暴了。事件风暴是一个领域建模的过程,实际上有一部分的工作是做用例分析,尽量全面的梳理业务的各种领域事件,找出实体、聚合等,根据业务语义划定限界上下文,建立领域模型,限界上下文是业务边界,也是微服务设计的边界。从领域模型到微服务还会有一个分析的过程。
微服务设计完成后,后面的开发方式就没什么区别了。
作者回复: 你可以把限界上下文理解成一个子域。
限界上下文是在事件风暴后产生的,在找出实体和聚合后,会将聚合归拢到限界上下文,让他们在同一个业务语义环境下工作。这样多个聚合一起就组成了限界上下文,完成特定的业务领域的功能,这个限界上下文是不是就是一个子域呢?
作者回复: 理赔相对保险领域来说是一个比较大的子域。由于子域过大不太容易做事件风暴,因此还需要继续细分子域。当子域细分到一定程度后,对这个子域的分析就比较容易了,很有可能这个子域就是一个限界上下文,所以这时候子子域的边界与限界上下文的边界是一致的。理赔不是一个微服务,需要根据不同子域事件风暴建立领域模型后,它其中的某个业务子域就是一个微服务,比如报案之类的。你说的这个工作流引擎是不是跨了很多的微服务,如果做统一协调,按照职能划分它应该是一个工作流微服务。另外,我简单分析一下,有的时候DDD的事件驱动可以替代工作流的功能,通过事件驱动推动业务在不同的领域模型中的流转。后面的章节会讲到。
作者回复: 就我了解来说还没有量化的划分方法。主要依赖项目团队和领域专家的判断。
在事件风暴时候,子域不能太大,要不你hold不住。其实你说的那个人的问题,做微服务设计时会有一些技巧的,尤其是分布式架构下。如果一个对象同时存在于两个微服务中,你可以考虑一定的数据冗余。其中的一个微服务这个对象是主要的业务环节,它可以被设计为实体,而在另外一个微服务中这个数据是冗余数据,它可以设计为值对象或者关联实体。
作者回复: 好的,下次注意一下。
作者回复: 用事件风暴建立领域模型后,我们还会进一步分析,确定更细的实体和值对象,以及各层的服务,这些都是领域对象。然后这些领域对象会跟代码模型中的数据实体,服务等代码对象建立映射关系。这个分析过程与传统的研发模式不太一样。
作者回复: 主要目的是把对象和行为放一起,面向对象嘛。DDD强调对象和它的行为。
作者回复: 你可以把范围扩大一点,就是领域模型中的对象,表格主要是为了记录这些对象。聚合根和实体属于实体对象。
作者回复: 第二遍的感觉跟第一遍相比,是否理解的更透彻一些了呢?
作者回复: 它是DDD分层架构中的一层,建议你看一下第7节的DDD分层架构。