若你是做业务后端开发同学，“数据流程图”绝对能帮助到你，更好的理解系统现状，更好评估需求开发工作量。

其它岗位同学，同样有很大帮助，从研发视角理解系统设计，更好理解研发的工作评估。

为什么要画图？

基于软件本身固有特性：

复杂性：一图胜千言。

业务本身的复杂性，用户规模增长带来的复杂性，一张好的架构图，能展示很多关键核心信息。

不可见性：图能帮助不同人更形象的理解而达成一致。

软件除了前端用户能看到部分页面，其实核心业务逻辑基本是不可见的。图能帮助不同人趋于形象的理解。

易变性：画草稿图， ROI 最高。

软件和硬件最大区别，在于它随时可变更的，软件相对于硬件变更成本很低，但量变引起质变，尤其在敏捷开发流程下，经常的变更，维护图的成本过高。

分布式系统，用图描述交互关系、数据流更直观。

分布式系统服务之间的调用关系，还是代码层面类之间的依赖关系，用图能描述的更形象和直观。

画图首要的还是为了梳理设计与想法，方便沟通和理解！

基于更好评估研发工作量：

1.你是否常出现过由于工作量评估不准确，导致被动加班？

2.你是否出现过工作量评估，其他人会提出质疑，如何更好阐述？

画图能帮助更好的评估工作量。

《UML精粹》中归纳使用UML的三种模式：草稿、蓝图和编程语言。

草稿：粗略画出即将要编码的东西，帮助沟通想法或展示所有做的事情的可选方案。草稿通常是非正式和动态的。不必严格遵循规范，草稿通常是探索性的。

• 图首要价值是帮助沟通和理解。

  • 好的图形经常可以帮助沟通设计思想，特别当你想回避许多细节时。
  • 帮助你理解软件系统和业务流程。
  • 有助于理解和沟通整个团队所理解到的东西。

蓝图：需要关心完整性和规范性。就像职业工程师创建工程图，移交给建筑公司来建造。蓝图是定义性的。

• 图当做蓝图。

  • 可以交由其他人员实施。在工业领域这是必须的，因为其返工的成本相当的高。软件由于易于变更，经常变更的特性，当做蓝图维护成本过高。
  • 囊括了工作的目标范围，是评估工作量的有效依据。

编程语言：模型驱动架构（MDA）。首先建模人员通过创建平台无关模型（Platform Independent Model,PIM）表达特定应用。PIM是独立于特定技术的UML模型。然后通过某种工具将PIM转为平台特定模型（Platform Specific Model,PSM）。

若果从PIM到PSM再到最终代码的过程是完全自动化的，我们就把UML当做了编程语言。若果其中有些步骤是手工的，我们就把UML当成了蓝图。

• 画图就是编程。

  • RUP（统一软件开发过程），UML图和代码间能相互转换。
  • 少儿编程，通过拖拽图形构建驱动流程程序控制机器人动作。
  • 低代码（aPaaS）平台，在局部应用还是挺多的，如动态表单设计器、审批流程设计器等。

PS：曾经在工作的第一家公司就有专门的系统分析师，系统设计文档写的相当详细，UML图形也尽可能符合规范。而后敏捷开发大行其道，为了快速迭代，强调沟通与适应变化，基本简化甚至有时略过系统设计评审，这样容易带来的风险就是关键细节掌握不全，工作量评估不准，不得不加班来完成承诺的工期。

把图当做草稿、蓝图、还是编程语言，核心在于投入产出比ROI。基于软件本身的特性之一易变性，如果把图作为蓝图，会显著增加双向维护的成本。在快速变化的互联网行业大多是当做草稿使用，用来沟通想法和帮助理解。

最常见的图，没多少约束规范，灵活自由使用场景广。软件开发的各个阶段各个角色都经常使用。

为便于识别，绘制流程图的习惯做法是：

圆角矩形表示“开始”与“结束”；

矩形表示行动方案、普通工作环节用；

菱形表示问题判断或判定（审核/审批/评审）环节；

用平行四边形表示输入输出；

箭头代表工作流方向。

审批流程图保存

由于流程图过于自由，在2004年出现了BPMN（Business Process Modeling Notation），用来描述业务流程建模，增加了很多图形元素，能表达更丰富的逻辑。但同时也带来了更高的学习和使用成本，所以现实情况，都基本只使用其几个基本的图形。其特定应用场景审批工作流的流程图绘制。

四种基本的类型：

1）流对象(Flow)

2）连接对象(Connection)

3）泳道(Swimlane)

4）人工信息(Artifact)

BPMN 1.1version挂图-来源网络

BPMN流程图示例-来源网络

信用卡购物流程-BPMN图

架构设计时通常会使用到各种架构图，有各种体系与方法论，TOGAF、C4、DDD、RUP（4+1视图）等。本文重点不在这，不做过多描述。

随着敏捷开发模式的流行，强调沟通优于文档，不再纠结于架构图的标准与规范，更多使用一些架构草图来帮助沟通与理解。

分类	方法论	描述
面向过程	结构化分析	面向过程的分析和设计
面向对象	RUP（包括4+1视图）	包括开发过程管理，设计管理还支持MDD
DDD	唯一的业务概念可以从战略层落地到战术层的一种方法论
C4	极度简化了UML，并添加了全景图等
企业架构	TOGAF	历史悠久，全面的架构设计与描述方法论，已经第10版了
MEAF	《ThoughtWorks现代企业架构框架白皮书_V4》中提出的MEAF，在TOGAF的基础简化并结合DDD形成的企业架构框架

但目前更主流的还是 masala 图。为什么要用 masala？Garbarino 认为是因为它灵活多变、能够一次性涵盖多个维度、既涉及结构又涉及行为、既体现逻辑层面又贯通物理层面，很像是 4+1 架构模型视图的大杂烩产物。

《UML 怎么就真“挂”了？ 2021 年 5 月 09 日》

masala图-来源red hat

UML统一建模语言，面向对象编程兴起后，诞生于1996年，是之后RUP的主要组成部分，UML建模一度比较流程流行。以前公司都有专门的系统分析师岗位（现在互联网公司基本见不到了），近年来随着敏捷开发大行其道，其重要性逐渐被忽视，而强调沟通和快速试错。除了类图、用例图、序列图其它都少见了。

《UML 怎么就真“挂”了？ 2021 年 5 月 09 日》

所以问题的答案是，死掉的并不是 UML 本身——它只是连带受害者。这场“大屠杀”波及到整个需求工程领域，包括业务分析与设计等等。下杀手的是“敏捷化”，正是它抹杀掉了 UML 以及关于它的一切。

Garbarino 认为，错不在 UML，人们只是放弃了业务分析与正式规范的僵化束缚：

数字化转型专家建议我们直接将方案部署在生产环境中，由客户用行动向我们展示实际需求，而非预先做出假设。在这样一套流程下，我们通过反复试错来找到正确答案。这就是所谓快速失败、快速迭代的新方法。

除了类图、序列图、状态机图，用例图其它都用的不多了。

UML图形分类

spring容器核心接口类图

支付服务-支付接口序列图

PlantUML

一种更简洁的，简单的逐行文本，就可绘制UML图。学习传送门plantuml.com/

飞书文档已经支持。如下示例：

PlantUML序列图-官方示例

支付集成序列图-示例

数据流图本身是一种特殊的流程图。

百度百科：数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

• 数据流图是分层的，通常3层：

  • 最顶层：描述系统给不同角色提供什么核心能力（核心用例），以及与外部实体的交互。
  • 0层：对于系统核心用例间的关系及数据存储、程序处理流程进行描述。
  • 1层：对具体的某一个用例进行更细节的描述。

• 4个主要元素：

数据流图-来源网络

20世纪70年代提出的数据流图模型，已经不是很适合描述现代大型分布式系统。

1.规范约束过于严格，灵活性差。最初主要用于需求分析阶段，但现实产品经理都很少使用。更多使用的是没什么约束且更灵活的流程图。

2.从技术视角来看，基于微服务架构，不能反映服务之间的调用关系，不能体现服务的边界。所以系分设计中更常见的是序列图、BPMN。

3.数据流图产生于结构化分析法中，是面向过程的，对于面向对象的编程不太适用。

有的时候业务逻辑条件分支过多时，不适合用流程图表示，绘制一张决策表是更好的做法。穷举分类列出所有组合。

例：基于飞书文档表格绘制的决策表示例如下：

审批操作决策表示例

什么时候画图？

任何时候都可以，只要你认为用语言表示困难的时候都可以画图来解释。画图同时能更好的帮助梳理设计与想法。

画图要画到哪种细节程度？

都可以，只要你认为图可以在评审和实现过程中表示清楚即可，对你自己评估工作量能提供有效帮助。 对于了解较详细，粒度可以粗一些，少些细节。对于新的需求系分设计时，操作级别的数据流程图，可以包括业务角色、页面、接口、表、锁、MQ、事务等关键涉及开发的元素，方便直观评估影响和依赖，评估工作量。

如何画好图？

图应该有层次，从上到下，逐层分解。

首先产品需求是有层次的：业务需求、功能需求、操作需求。有对应的产品架构图、流程图等。

• 业务需求：目标性需求，定义整个系统需要达到的目标。高层关注的，如字节的6大业务板块，在这一层次也可以再分层，如从飞书-》飞书费控-》飞书费控对私报销、对公支出等。

• 功能需求：功能性需求，定义了整个系统必须完成的任务。中层关注，如费控包含单据、费用标准、发票、审批、支付、预算等领域模块。

• 操作需求：用户操作需求，定义了完成每个任务的具体的人机交互。基层关注，如审批包含提单、审批通过、审批拒绝、撤回、加签、分享等操作。

同样软件设计是有层次的：有一句说“软件设计上有什么问题解决不了的，那就增加一层。” 经典的如OSI七层模型，架构C4分层模型，DDD分层模型等。

系统设计上通常也可以分为三层：业务架构、领域关系、操作流程。对于复杂每层内可以在分层。

业务架构：

通常对应应用架构的分层模型。通常分为用户层、业务产品层、核心业务服务层、基础通用服务层、基础设施层等。通常出现在整体性的系统架构的文档中。主要价值可以帮助梳理业务与技术架构规划方向。

支付系统架构分层示例

领域关系：

一个领域与其它领域服务之间的交互关系，对于微服务架构，服务之间依赖关系，画图的重点是梳理服务是否存在有环依赖。服务之间直接调用关系应是有向无环。当出现环时通过异步通知解耦。

一个中等复杂功能需求通常会涉及多个服务之间的调用关系。通常在系分设计文档中要包含该部分内容，它描述了整个需求开发涉及的各个服务。主要价值是识别涉及哪些服务、哪些人要参与开发工作。

支付收单流程-服务调用关系图示例

对于功能需求，基于微服务架构特点，通常可以画一张接口全景图，列出该需求涉及的各个服务相关的接口，方便一眼直观看到需求依赖与影响范围。然后列出每个接口的协议并与上下游达成一致，这是正式开发前的核心工作，否则很容易造成上下游理解不一致，工作量评估不准。

审批分享、拉群需求-接口全景图示例

操作流程：

画数据流程图，描述具体一个用例或操作的完整调用链路，包括业务角色、前端页面、接口和网络 IO （上游服务、数据库表、缓存、 MQ 、下游服务等）。 这一层描述的东西是要通过代码实现的具体内容了 。 主要价值是梳理识别操作流程设计是否合理，对评估研发工作量提供有效帮助。 在系分设计文档中应该必须包含的。从流程图上就应看出关键的业务逻辑、依赖什么。重点体现当次需求涉及的内容。

报销流程审批通过-数据流程图

分布式系统应关注数据、接口与网络IO。

通常流程图主要关注流程动作、流程方向以及条件判断。都不太关注数据的存储与访问，但这点很重要。

程序=数据+算法=数据+（业务逻辑+控制逻辑），而调用链路描述了在分布式系统中，一个用例或功能的控制逻辑。另外分布式系统接口的响应时间和流程的设计有直接关系。优化接口性能首先最重要的是减少不必要的网络IO。

在用例和功能级别数据流程图上，应该包含前端页面，接口、表、缓存、MQ、定时任务等。并串联起来，另外还可以包含关键的业务逻辑。如果它会占用不少的研发工作时间，那就应该体现出来，有助于更好的评估工作量。

简单清晰优于图形规范，善用颜色区分。

不同的图形体系，同样的图标代表的含义是不一样，比如圆角矩形在普通流程图中表示开始或结束，但在BPMN中表示流程或任务，我个人而言，图更多的是当做草稿使用，所以不过多纠结于规范。

流程方向是清晰的，保持有向无环。

能清晰的表达出要做的事情，用什么图形表示什么内容，保持个人统一的风格规范即可。

比如个人习惯用的数据流程图元素：

用不同颜色来区分新增、变更、删除。

为什么用数据流程图？

这里说的数据流程图，非前文的数据流图。数据流程图主要是基于微服务架构特点，在普通流程图基础上强调数据、接口、网络IO等，以及数据之间的关系，甚至锁、事务范围等。画图会比写大量文字更省时，同时能更好梳理业务流程。从图上能直观更直观看出设计是否完整和合理。

要描述系统业务流程，数据流程图、BPMN、PlantUML序列图，使用哪种都可以，各有优缺点，形式不是最重要，关键图中要体现出完整业务流程、主要的工作事项。兼顾时间成本，选择自己最顺手的即可。

基于个人的习惯与经验，在描述业务流程时会关注数据流，数据流程图更灵活自由。而在编写代码设计类的调用关系时常用序列图。

示例：财务操作收单后，如果当前用户是该单据的财务一审，则尝试自动审批通过。分别用数据流程图、BPMN、PlantUML序列图来表示。

财务收单自动审批-数据流程图

财务收单自动审批-数据流程图BPMN

财务收单自动审批-PlantUML序列图

从20世纪60年代软件开发快速发展，无数的软件大神们，期望像工业界一样，有专门的“设计人员”绘制好图，就能交由任意“施工团队”去实施。涌现了各种图形标准以及相关的工具。但现实是半个世纪过去了，基于软件本身的特性，才发现没有“银弹”。开发一个软件容易，但要开发一个优秀的软件真的不容易。当然图的价值仍在，帮助沟通，更好梳理系统设计，工作量评估。

最后，顺便说一下，以上各种图飞书文档都原生支持！！！

画图最为了梳理设计和想法。

画图是为了方便沟通和理解。

画图是为了更准评估工作量！

加入我们

我们来自字节跳动飞书商业应用研发部(Lark Business Applications)，目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。我们关注的产品领域主要在企业经验管理软件上，包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统，也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统。欢迎各位加入我们。

扫码发现职位&投递简历

官网投递：job.toutiao.com/s/FyL7DRg