阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 技术琐话 「胡正军」欢迎转载，保留摘要，谢谢！

• 业务系统的核心元素
  • 计算机程序=算法+数据结构
  • 业务系统=业务流程+领域模型
  • 两图两表法
  • 总结

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

前言

接一年多前的上篇（小团队也能做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种：继承，聚合，关联。下图是一个例子：

具体可以参考如下步骤：

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

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

1. 根据子域来识别限界上下文，那么子域如何得到呢？我们通过分解问题域的方式，将整个问题域分解成若干个更小、更简单、更容易解决的问题子域。

2. 一个限界上下文边界内，实体的含义是不存在二义性的。如果存在两个人对一个实体理解不同，那这个实体说明有二义性，很可能是这个实体要分离成两个实体，放到不同的限界上下文。举个例子，商品管理，销售订单，发货三个业务都有商品的概念，表面看好像是同一个实体，深入分析实际是不同的实体，销售订单里面商品其实是订单项，发货业务的商品关注的是大小，重量等，实际上是货品，所以这里是三个不同的限界上下文，每个限界上下文里面都有一个“商品”实体，命名上要区分开。

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

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

总结

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