小团队也能做DDD

前言

接一年多前的上篇（小团队也能做DDD），上篇主要讲了为什么，这篇核心讲下怎么做。从上篇的分析可以看出领域模型是一个核心产出物，有了领域模型，限界上下文和代码模型就可以产出，最终落地到微服务和具体的代码。本文先介绍业务系统的核心元素，再讲产出领域模型的一个方法：两图两表法，最后做个总结。

业务系统的核心元素

在讲怎么产出领域模型之前，回顾下一个业务系统最重要的东西是什么，先看1个公式：

计算机程序=算法+数据结构

这个公式是大学课本里见到过，是图灵奖得主:尼古拉斯·沃斯提出的，那我们平常做得多的软件是业务系统，看起来也没什么算法，数据结构用List,Map之外也没用过多么高大上的东西，明显不太符合大师的这个公式。我们换个思路，先做类比，把程序当作一个人的话，数据结构是心肝脾肺肾各种器官，相对静态不动；算法是血液，动态输送到器官，影响器官。从这个角度看业务系统的血液是业务流程，器官是领域模型，业务流程代表业务流转过程，这个过程中操作领域模型，所以我们得出如下一个公式：

业务系统=业务流程+领域模型

这个公式是上一个公式的变种，能较好的描述业务系统，可以说是业务系统的结构化表达，为了梳理出业务系统的这两个核心元素，我们讲下一个领域建模的两图两表法，这个方法相对比较简单，也好操作，方便落地。

两图两表法

这个方法是自己的一个总结，学习了不少专家的文章和书籍，先看定义：

为了避免扯皮，上面表格里面给了4个产出物由什么角色产出合适。由于业务术语，业务流程偏向需求分析，所以由需求分析人员产出相对合理，角色目标实体表需要两个角色一起产出，领域模型图虽然说也是可以由需求分析人员产出，但这里毕竟跟代码模型牵扯比较紧密，我建议是业务系统架构师产出，再跟需求分析人员和领域专家达成一致，也可以根据团队成员的情况来，有些需求分析人员对软件抽象掌握比较好，产出领域模型也是可以的。

详细步骤如下：

接下来针对每个产出物做解释。

业务术语表

目的是统一语言，减少沟通障碍，简单说就是名词解释，如果一个术语比较复杂，要用why,what,how来解释清楚，这三个东西不是每个术语都得写，要看某一项是否明确，比如what非常清楚，就可以省略。特别强调的是我们经常忘记写为什么，导致业务术语看不懂

业务术语表的一个简单模板如下：

业务流程图

业务流程能描述业务整体流转过程，串起业务活动，是数字化起点。流程图分为两类：业务流程（以人为基础），系统流程（以物为基础）。这两个流程图的出发点不一样，是先有业务流程再有系统流程，两者不可混淆在一起。流程图常用的展现形式是泳道图，对于业务流程，因为是以人为基础，那么每条泳道代表一个业务角色。

流程图有一个难点在于粒度，对于DDD而言，已经到了一个具体问题域的业务分析，这个需要落地到需求开发，流程图粒度直接到具体的业务角色需要干什么事情，才能有效的指导开发。多提一句，企业架构里面对流程有个PCF流程分级方法，我们这里提到的具体流程算是L3级流程。拿中国地图举例说明下流程分级，L1级流程是一个国家省的划分，L2级流程是对某个省做城市的划分，L3级流程是对城市做乡镇的划分。可以看到高阶抽象的流程是为了看范围更大，更复杂的企业级的业务过程，这属于企业架构内容，感兴趣的同学可以学习这块，企业架构+DDD非常配。

下图是一个员工请假的业务流程图：

角色目标实体表

角色目标实体表是为了梳理业务实体，我们的业务流程跟业务实体到底怎么关联起来，业务实体不是凭空产生的，就是通过这个角色目标实体表，这个方法从Thoughtworks徐昊的文章里面提到过,我觉得比事件风暴要容易学习和落地，毕竟学得会的方法才是好方法。具体方法是把业务角色全部列出来，然后顺着业务流程，梳理出用例，过程中出现的名词，就是涉及的实体。看例子：

上表是个非常简单的场景，企业的业务远比这个要复杂，仅仅用来说明角色目标实体表的形态，可以看到这个表相当于把用例和实体结合起来。

领域模型图

领域模型图是本文的最终目标，是软件的骨架。角色目标实体表产出的实体，用UML图表达出来，就形成了领域模型图。实体和实体的关系大体有3种：继承，聚合，关联。下图是一个例子：

具体可以参考如下步骤：

1. 把角色目标实体表的所有实体画出来
2. 根据继承，聚合，关联3种关系对实体进行连线，聚合可以用一个虚线框框出来
3. 多个聚合组合成限界上下文
4. 团队共识消化，对于缺少的实体进行补充等

这个步骤的难点在于第4步，怎么合理的划分出限界上下文。要做到划分后的限界上下文之间的接口最少，这个最优解肯定存在，但比较依赖经验，有经验的架构师深刻理解高内聚低耦合，一把到位。怎么划分这里也给出一些建议：

1. 根据子域来识别限界上下文，那么子域如何得到呢？我们通过分解问题域的方式，将整个问题域分解成若干个更小、更简单、更容易解决的问题子域。
   
2. 一个限界上下文边界内，实体的含义是不存在二义性的。如果存在两个人对一个实体理解不同，那这个实体说明有二义性，很可能是这个实体要分离成两个实体，放到不同的限界上下文。举个例子，商品管理，销售订单，发货三个业务都有商品的概念，表面看好像是同一个实体，深入分析实际是不同的实体，销售订单里面商品其实是订单项，发货业务的商品关注的是大小，重量等，实际上是货品，所以这里是三个不同的限界上下文，每个限界上下文里面都有一个“商品”实体，命名上要区分开。
   

3. 限界上下文分不清就先别分了，减少扯皮，团队内共识后，迭代演进。

领域模型图产出后，需要拉上领域专家一起共识，当然很多团队要做到这个不现实，那就尽最大范围去共识，形成统一语言。接下来领域模型就可以给代码开发提供输入了，我们可以把梳理的领域模型都放到一个单体系统来实现，每个限界上下文是一个package，这个是最简单的，如果实在要做微服务拆分，限界上下文这个业务边界也是优先考虑的，除此以外还要综合考虑弹性边界，组织架构等问题了，这个属于微服务拆分的话题了。

总结

业务流程和领域模型构成业务系统的核心要素，业务流程升级到业务价值流，领域模型升级到企业级业务对象，这就变成了企业架构的方法（价值流+业务能力+业务对象），所以DDD和企业架构方法是相通的，一个是微观，一个是宏观，两者结合可以更好的认识数字化建设。最后预告下篇内容，上代码模型。