DDD:用 “四色原型” 进行 “聚合设计”

四色原型

在企业应用的上下文中,四色原型是领域模型的一种原型,原型的意思是指领域中的任何模型及其关系都可以抽象为“四色原型”。

四色原型可以用这句话进行描述:某个人(Party)的角色(PartyRole)在某个地点(Place)的角色(PlaceRole)用某个东西(Thing)的角色(ThingRole)做了某件事情(MomentInterval)。

图片示意

名词解释

  • PartPlaceThing:简称PPT,用淡绿色表示,常见的PPT有:部门、岗位、人员、地点、物品等。
  • Description:简称Des,用淡蓝色表示,主要用来对PPT进行描述,常见的Des有:部门类型、岗位层级、人员类型、地点区域、物品分类等。
  • Role:用淡黄色表示,主要表示PPT在某个场景下扮演的角色,常见的角色有:财务类部门、管理类岗位、请假者、销售点、产品等。
  • MomentInterval:简称MI,用淡红色表示,主要表示在一刻或一段时间内发生的一件事情,常见的MI有:部门移动、岗位移动、员工离职、产品销售等。
  • MomentInteval:简称MIDetail,用淡红色表示,主要表示MI的明细,常见的MIDetail有销售明细、入库明细、出库明细等。

出差管理示例

根据四色原型进行聚合设计(四步曲)

第一步:识别模型

根据四色原型很容易识别出领域模型(见上图)。

第二步:识别关联

根据四色原型同样很容易识别出领域模型之间的关系(见上图)。

第三步:划分聚合

  • MI和MIDetail是一个聚合,MI是聚合根。
  • PPT是一个聚合,PPT是一个聚合根。如果Des只“描述”PPT,那么这个Des会作为一个值对象隶属于属于PPT所在的聚合。
  • Des是一个聚合,Des是一个聚合根。前提你想“跟踪”Des关联的PPT。
  • Role不属于聚合,Role是一个带状态的领域服务,Role采用装饰器模式装饰PPT。

划分结果

第四步:精简关联

  • 去掉MI和Role之间的关联,改为仓储查询,根据需要让MI关联一个Role的快照(发生时刻Role的状态)。将关联改为仓储查询的理由是这样更加灵活,一个请假人有1W个请假单,没有必要设置这样的关联。让MI关联一个Role的快照的理由是MI很多情况要记录下发生时刻Role的状态,如:出差单要记录下发生时刻请假人的组织信息,而不是现在的组织信息。
  • PPT和DES之间的关联可以根据自己的爱好酌情保留,我喜欢用仓储查询,这样更灵活。
  • 去掉PPT和Role之间的关联,改为仓储查询。比如:用仓储查出PPT,然后将这个PPT实例注入到Role中。

精简结果

为什么销售单和销售单明细是一个聚合,而文章和评论不是一个聚合呢?

因为销售单是MI,销售单明细是MIDetail,因此他们是一个聚合;而文章是MI,评论也是MI,所以他们不是一个聚合。

备注

四色原型可以帮助我们做聚合设计,我相当于把聚合设计问题踢给四色原型分析了,本文还没有详细讨论如何识别领域中的四色原型。当然了,聚合设计还有其他规律可循,后面慢慢讨论吧。时间有限,后面我会用HappyFramework写个Demo。

今天还没有过多的谈“职责分配”的问题,四色原型可以完美的补充DDD关于职责分配的各种模式,我会放到下一个主题讨论。

posted on 2013-04-26 07:02  幸福框架  阅读(12138)  评论(11编辑  收藏  举报

导航

我要啦免费统计