案例教你一步步设计DDD微服务项目(中)

定义限界上下文

人员组织关系和请假,两个聚合共同完成请假业务,所以在请假限界上下文。

考勤聚合单独构成考勤统计限界上下文。

所以为业务划分请假和考勤统计两个限界上下文,建立请假和考勤两个领域模型。

微服务的拆分

一般来说,一个限界上下文即可设计为一个微服务。

划分微服务主要考虑职责单一原则。根据限界上下文即可拆为请假和考勤两个微服务:

  • 请假微服务包含人员组织关系和请假两个聚合
  • 考勤微服务包含考勤聚合

战略设计结束。通过战略设计建立了领域模型,划分了微服务边界。

下一步战术设计了,即微服务设计。

战术设计

根据领域模型进行微服务设计的过程。

梳理微服务内的领域对象,梳理领域对象之间的关系,确定它们在代码模型和分层架构中的位置,建立领域模型与微服务模型的映射关系,以及服务之间的依赖关系。

战术设计包括如下阶段:

分析微服务领域对象

领域模型有很多领域对象,但这些对象带有比较重的业务属性。

微服务内应该有哪些服务?服务的分层?应用服务由哪些服务组合和编排完成?领域服务包括哪些实体和实体方法?哪个实体是聚合根?实体有哪些属性和方法?哪些对象应该设计为值对象等。

服务的识别和设计

可将命令作为服务识别和设计的起点,步骤如下:

  • 根据命令设计应用服务,确定应用服务的功能,服务集合,组合和编排方式。服务集合中的服务包括领域服务或其它微服务的应用服务
  • 根据应用服务功能要求设计领域服务,定义领域服务。这里需要注意:应用服务可能是由多个聚合的领域服务组合而成的
  • 根据领域服务的功能,确定领域服务内的实体以及功能
  • 设计实体基本属性和方法

考虑领域事件的异步化处理。

以提交审批为例,流程:

  • 根据请假类型和时长,查询请假审批规则,获取下一步审批人的角色
  • 根据审批角色从人员组织关系中查询下一审批人
  • 为请假单分配审批人,并将审批规则保存至请假单
  • 分析得需要在应用层和领域层设计以下服务和方法
  1. 应用层
    提交审批应用服务。
  2. 领域层
    领域服务有查询审批规则、修改请假流程信息服务、根据审批规则查询审批人服务,分别位于请假和人员组织关系聚合。
    请假单实体有修改请假流程信息方法,审批规则值对象有查询审批规则方法。
    人员实体有根据审批规则查询审批人方法

案例教你一步步设计DDD微服务项目(中)

聚合中的对象

请假聚合中,聚合根是请假单。

请假单经多级审批后,会产生多条审批意见,为方便查询,可将审批意见设计为实体。

请假审批通过后,会产生请假审批通过的领域事件,因此还会有请假事件实体。

请假聚合有如下实体:

  • 审批意见(审批人、审批状态和审批意见)
  • 请假事件实体

请假单聚合的值对象。请假人和下一审批人数据来源于人员组织关系聚合中的人员实体,可设计为值对象。

人员类型、请假类型和审批状态是枚举类型,可设为值对象。

确定请假审批规则后,审批规则也可作为请假单的值对象。请假单聚合将包含以下值对象:请假人、人员类型、请假类型、下一审批人、审批状态和审批规则。

  • 请假聚合对象关系图
  • 案例教你一步步设计DDD微服务项目(中)
  • 人员组织关系聚合中,可建立人员之间的组织关系,通过组织关系类型找到上级审批领导。
  • 聚合根
    人员
  • 实体
    组织关系(包括组织关系类型和上级审批领导),其中组织关系类型(如项目经理、处长、总经理等)是值对象。上级审批领导来源于人员聚合根,可设计为值对象
    人员组织关系聚合包含以下值对象
  • 组织关系类型
  • 上级审批领导
  • 人员组织关系聚合对象关系图
  • 案例教你一步步设计DDD微服务项目(中)
  • 在确定各领域对象的属性后,我们就可以设计各领域对象在代码模型中的代码对象(包括代码对象的包名、类名和方法名),建立领域对象与代码对象的一一映射关系了。根据这种映射关系,相关人员可快速定位到业务逻辑所在的代码位置。在经过以上分析后,我们在微服务内就可以分析出如下图的对象清单。
上一篇:PostgreSQL:系统表pg_attribute膨胀解决方案


下一篇:如何选择云主机