领域驱动设计（DDD）理论与方法

DDD领域驱动设计通常会包含战略设计和战术设计两部分：

　　战略设计：重业务建模，以业务视角，拆分领域，通过事件风暴（从发散到收敛过程），梳理业务并构建领域模型，这块过程会涉及业务人员、产品人员、架构师等多方参与；

　　战术设计：重落地实现，以构建的领域模型，建立了领域模型的边界与上下文，也就确认了微服务的边界，这个过程会涉及架构师、技术人员参与；

 

下面的图展示了DDD设计开发的一般步骤和涉及到的战略设计和战术设计相关的概念与要素：

 

 

 

分析方法：

　　用5W2H进行分析：

　　　　用户（WHO）在什么环境（WHERE）下遇到什么时机（WHEN）因为什么（WHY）产生什么目标（WHAT），继而通过什么方法（HOW）去达成目标。

　　

　　四色原型：

　　　　时刻-时段原型（Moment-Interval Archetype，简称MI）：一段时间内发生的业务，包括与业务相关的数据以及行为。使用粉红颜色表示。

　　　　角色原型（Role Archetype）：任何一个系统都需要某种人或某种组织介入运行，例如：论坛系统需要注册者角色发言。使用黄色标识。

　　　　参与方-地点-物品原型（Part-Place-Thing Archetype，简称PPT）：表示参与不同角色的参与方、或者地点、或者事物。其中，Part表示有自主行为的，例如：人；place、thing表示没有自主行为，如：某个地方或者事物，具体如“商品可以在不同场景扮演不同的角色”。使用绿色表示。

　　　　描述原型（Description Archetype，简称DESC）：Desc是对PPT的抽象概括或总结。例如：一个人可以用身份证号码、身高、体重、喜好来概括描述。用蓝色表示。

 

　　事件风暴：

　　　　是一项团队活动，是一种快速探索复杂业务领域和对领域建模的实践。旨在通过领域事件识别出聚合根，进而划分微服务的限界上下文。

 

　　　　具体方式：

　　　　　　在活动中，团队先通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令（Command），再然后为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。

 

　　　　概念说明：

　　　　　　命令是外部的一些操作和业务行为，也是微服务对外提供的能力。

　　　　　　领域事件是领域模型的组成部分，表示领域中所发生的事情，对业务有价值，即在同一个领域中其他部分知道并产生后续动作的事件。

　　　　　　　　以宠物为例：

　　　　　　　　　　如果做为宠物主人，你的问题域是如何养好一只猫，那么是不是已经打了疫苗，给宠物饲喂食物等将成为你关注的事情。领域事件会有：疫苗已注射，猫粮已饲喂等。

　　　　　　　　　　如果你是宠物医生，问题域是如何治好宠物的病，关注的事情是宠物的身体构成，准确的诊断宠物病情，对症下药。领域事件会有：病情已确诊，药方已开治。

　　　　　　　　虽说二者关注的都是宠物，在不同的问题域下领域事件是不同的。

　　　　

 

案例分析：

　　案例1、通过“燃气缴费”案例结合"5W2H分析法"和"四色原型"来描述DDD建模过程：

　　　　“燃气抄表计费场景每月末，燃气公司制定抄表计划并批量生成抄表任务，抄表任务通过工单的形式下发到抄表人员到客户现场抄表，抄表完成之后给客户应收账单，客户可以现场缴费或者延后通过在线自助缴费。下面以此案例描述建模步骤。”

　　对比

　　案例2、“请假考勤”采用“事件风暴”建模过程：

　　　　“请假人填写请假单提交审批，根据请假人身份、请假类型和请假天数进行校验，根据审批规则逐级递交上级审批，逐级核批通过则完成审批，否则审批不通过退回申请人。根据考勤规则，核销请假数据后，对考勤数据进行校验，输出考勤统计。”

 

 

具体步骤：

　　1、业务场景描述：

　　　　案例1、获得“需求场景清单”；

　　　　　　

　　VS

　　　　案例2、事件风暴的第1步，获得“产品愿景”。产品愿景是对产品顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。

　　　　　　在线请假考勤系统，从产品愿景中可以明确项目目标和关键功能，与竞品（HR）的关键差异以及自己的优势和核心竞争力等。

　　　　

 

 

 

 

　　2、业务流程梳理：串联业务场景采用“业务流程”进行描述；

　      　

 

　　3、寻找时标性对象：即可追溯的业务事件。将业务流程分解到业务过程。

　　　　

 

　　　　这些时标性对象（用红色标记）的关系描述出来，就得到了领域模型的骨干：

　　　　　　　　

 

　　　　4、寻找时标对象周围的“人、地、物”（即ppt）：用绿色表示“时标对象周围”的“人、地、物”

　　　　

 

　　　　5、抽象“角色”：黄色表示。

　　　　

 

　　　　6、补充“描述”信息：描述对象包括“人、地、物”和时标对象，用蓝色表示；

　　　　

 

　　VS　　

　　案例2、事件风暴的第2步，可以对标上面的2、3、4、5、6步骤。

　　　　　　做场景分析。场景分析是从用户视角出发，探索业务领域中的典型场景，产出领域中需要支撑的场景分类、用例操作以及不同子域之间的依赖关系。如下图：

　　　　　　

 

　　　　

 

　　　　7、 划分限界上下文：抄表缴费属于核心业务，将业务过程中的时标对象都划分到核心子域

　　　　

 

　　　　8、确定聚合及聚合根：在每个上下文中，对时标对象中的概念按照相近原则划分为不同的组，形成新的聚合，然后选出聚合根作为与外界交互的代表。 比如：抄表时标对象产出的核心数据是待缴费的应收账单，关联对象涉及到抄表员、客户和表具，而其他暂时无法分组的概念或属性独立为值对象。浅绿色代表聚合根。

　　　　

 

　　　　　　其他：

　　　　　　

 

　　VS　　

　　　　案例2、事件风暴的第3、4、5步。第3步、找领域实体和值对象等领域对象；第4步、找出聚合根，根据实体、值对象与聚合根的依赖关系，建立聚合；第4步、根据业务及语义边界等因素，定义限界上下文。

　　　　　　第3步：找出发起或产生这些命令或领域事件的实体和值对象，并将命令和事件聚集到实体。

　　　　

 

　　　　　　第4步： 定义聚合。先找出聚合根（从上面的实体中，我们可以找出“请假单”和“人员”两个聚合根），然后找出与聚合根紧密依赖的实体和值对象。我们发现审批意见、审批规则和请假单紧密关联；组织关系和人员紧密关联；还有刷卡明细、考勤明细和考勤统计，这几个实体没有聚合根，它们之间相互独立，不是富领域模型，这时可以抽象一个聚合根，也可以直接放一起各自直接对外（而非聚合根来对外）。

　　　　　　

 

　　　　　　第5步： 定义限界上下文。根据聚会的业务关联性，分成不同的限界上下文。

　　　　　　　　　　人员组织关系聚合与请假聚合，共同完成请假的业务功能，两者在请假的限界上下文内。考勤聚合则单独构成考勤统计限界上下文。即建立请假和考勤两个领域模型。

 

　　　　　　

 　　　　9、 优化调整子域划分：例如：客户和表具在多个上下文中共用，是可以将其独立出来，作为共享上下文，划分到通用子域中。缴费环节，因为支付通常作为基础功能，也划分到独立的支撑子域；

　　　　　　

 　　　　

　　VS　　

　　　　案例2、事件风暴，也可调整建立的领域模型。

 

　　　　

　　　　

学习资料：https://www.jianshu.com/p/fbeaa3da6c43

　　https://cloud.tencent.com/developer/article/1837097