本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com
👉 这是一个或许对你有用****的社群
🐱 一对一交流 / 面试小册 / 简历优化 / 求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：
《项目实战（视频）》：从书中学，往事上 “练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然
👉这是一个或许对你有用的开源项目
国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。
功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能：
Boot 仓库：https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud 仓库：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn
【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本
前言
接一年多前的上篇（小团队也能做 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 和企业架构方法是相通的，一个是微观，一个是宏观，两者结合可以更好的认识数字化建设。最后预告下篇内容，上代码模型。
欢迎加入我的知识星球，全面提升技术能力。
👉 加入方式，“长按” 或 “扫描” 下方二维码噢：
星球的内容包括：项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
1335
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
