本文转自:技术琐话
前言
接一年多前的上篇(小团队也能做DDD),上篇主要讲了为什么,这篇核心讲下怎么做。从上篇的分析可以看出领域模型是一个核心产出物,有了领域模型,限界上下文和代码模型就可以产出,最终落地到微服务和具体的代码。本文先介绍业务系统的核心元素,再讲产出领域模型的一个方法:两图两表法,最后做个总结。
业务系统的核心元素
在讲怎么产出领域模型之前,回顾下一个业务系统最重要的东西是什么,先看1个公式:
计算机程序=算法+数据结构
这个公式是大学课本里见到过,是图灵奖得主:尼古拉斯·沃斯提出的,那我们平常做得多的软件是业务系统,看起来也没什么算法,数据结构用List,Map之外也没用过多么高大上的东西,明显不太符合大师的这个公式。我们换个思路,先做类比,把程序当作一个人的话,数据结构是心肝脾肺肾各种器官,相对静态不动;算法是血液,动态输送到器官,影响器官。从这个角度看业务系统的血液是业务流程,器官是领域模型,业务流程代表业务流转过程,这个过程中操作领域模型,所以我们得出如下一个公式:
业务系统=业务流程+领域模型
这个公式是上一个公式的变种,能较好的描述业务系统,可以说是业务系统的结构化表达,为了梳理出业务系统的这两个核心元素,我们讲下一个领域建模的两图两表法,这个方法相对比较简单,也好操作,方便落地。
两图两表法
这个方法是自己的一个总结,学习了不少专家的文章和书籍,先看定义:
目的 | 谁产出 | |
业务术语表 | 统一语言,去歧义 | 需求分析人员 |
业务流程图 | 梳理流程,观大局 | 需求分析人员 |
角色目标实体表 | 用例整理,列实体 | 需求分析人员或者架构师 |
领域模型图 | 实体建模,画结构 | 业务系统架构师 |
为了避免扯皮,上面表格里面给了4个产出物由什么角色产出合适。由于业务术语,业务流程偏向需求分析,所以由需求分析人员产出相对合理,角色目标实体表需要两个角色一起产出,领域模型图虽然说也是可以由需求分析人员产出,但这里毕竟跟代码模型牵扯比较紧密,我建议是业务系统架构师产出,再跟需求分析人员和领域专家达成一致,也可以根据团队成员的情况来,有些需求分析人员对软件抽象掌握比较好,产出领域模型也是可以的。
详细步骤如下:
接下来针对每个产出物做解释。
业务术语表
目的是统一语言,减少沟通障碍,简单说就是名词解释,如果一个术语比较复杂,要用why,what,how来解释清楚,这三个东西不是每个术语都得写,要看某一项是否明确,比如what非常清楚,就可以省略。特别强调的是我们经常忘记写为什么,导致业务术语看不懂
业务术语表的一个简单模板如下:
术语 / 缩略词 | 英文 | 说明 |
XXX | XXX | XXX (为什么,是什么,怎么做), |
购物车 | Shopping Cart | 用户浏览很多商品时,方便用户暂存感兴趣的商品,通过加入购物车完成商品的暂存 |
业务流程图
业务流程能描述业务整体流转过程,串起业务活动,是数字化起点。流程图分为两类:业务流程(以人为基础),系统流程(以物为基础)。这两个流程图的出发点不一样,是先有业务流程再有系统流程,两者不可混淆在一起。流程图常用的展现形式是泳道图,对于业务流程,因为是以人为基础,那么每条泳道代表一个业务角色。
流程图有一个难点在于粒度,对于DDD而言,已经到了一个具体问题域的业务分析,这个需要落地到需求开发,流程图粒度直接到具体的业务角色需要干什么事情,才能有效的指导开发。多提一句,企业架构里面对流程有个PCF流程分级方法,我们这里提到的具体流程算是L3级流程。拿中国地图举例说明下流程分级,L1级流程是一个国家省的划分,L2级流程是对某个省做城市的划分,L3级流程是对城市做乡镇的划分。可以看到高阶抽象的流程是为了看范围更大,更复杂的企业级的业务过程,这属于企业架构内容,感兴趣的同学可以学习这块,企业架构+DDD非常配。
下图是一个员工请假的业务流程图:
角色目标实体表
角色目标实体表是为了梳理业务实体,我们的业务流程跟业务实体到底怎么关联起来,业务实体不是凭空产生的,就是通过这个角色目标实体表,这个方法从Thoughtworks徐昊的文章里面提到过,我觉得比事件风暴要容易学习和落地,毕竟学得会的方法才是好方法。具体方法是把业务角色全部列出来,然后顺着业务流程,梳理出用例,过程中出现的名词,就是涉及的实体。看例子:
角色 | 目标 | 干啥(XX地方做XX动作) | 实体 |
员工 | 请假获得批准 | HR系统或者邮件发起申请 | 请假单 |
上级 | 审批员工的请假 | 根据员工的假期进行请假审批 | 请假单,员工,员工假期 |
HR | 维护好员工的假期 | 邮件类申请在HR系统做好员工的假期备案,留下变更记录 | 员工,员工假期,假期变更记录 |
上表是个非常简单的场景,企业的业务远比这个要复杂,仅仅用来说明角色目标实体表的形态,可以看到这个表相当于把用例和实体结合起来。
领域模型图
领域模型图是本文的最终目标,是软件的骨架。角色目标实体表产出的实体,用UML图表达出来,就形成了领域模型图。实体和实体的关系大体有3种:继承,聚合,关联。下图是一个例子:
具体可以参考如下步骤:
-
把角色目标实体表的所有实体画出来
-
根据继承,聚合,关联3种关系对实体进行连线,聚合可以用一个虚线框框出来
-
多个聚合组合成限界上下文
-
团队共识消化,对于缺少的实体进行补充等
这个步骤的难点在于第4步,怎么合理的划分出限界上下文。要做到划分后的限界上下文之间的接口最少,这个最优解肯定存在,但比较依赖经验,有经验的架构师深刻理解高内聚低耦合,一把到位。怎么划分这里也给出一些建议:
-
根据子域来识别限界上下文,那么子域如何得到呢?我们通过分解问题域的方式,将整个问题域分解成若干个更小、更简单、更容易解决的问题子域。
-
一个限界上下文边界内,实体的含义是不存在二义性的。如果存在两个人对一个实体理解不同,那这个实体说明有二义性,很可能是这个实体要分离成两个实体,放到不同的限界上下文。举个例子,商品管理,销售订单,发货三个业务都有商品的概念,表面看好像是同一个实体,深入分析实际是不同的实体,销售订单里面商品其实是订单项,发货业务的商品关注的是大小,重量等,实际上是货品,所以这里是三个不同的限界上下文,每个限界上下文里面都有一个“商品”实体,命名上要区分开。
-
限界上下文分不清就先别分了,减少扯皮,团队内共识后,迭代演进。
领域模型图产出后,需要拉上领域专家一起共识,当然很多团队要做到这个不现实,那就尽最大范围去共识,形成统一语言。接下来领域模型就可以给代码开发提供输入了,我们可以把梳理的领域模型都放到一个单体系统来实现,每个限界上下文是一个package,这个是最简单的,如果实在要做微服务拆分,限界上下文这个业务边界也是优先考虑的,除此以外还要综合考虑弹性边界,组织架构等问题了,这个属于微服务拆分的话题了。
总结
业务流程和领域模型构成业务系统的核心要素,业务流程升级到业务价值流,领域模型升级到企业级业务对象,这就变成了企业架构的方法(价值流+业务能力+业务对象),所以DDD和企业架构方法是相通的,一个是微观,一个是宏观,两者结合可以更好的认识数字化建设。最后预告下篇内容,上代码模型。