需求分析师该如何开展业务建模

01 业务架构和业务建模

通常在实际的项目实践中很多BA或产品经理其实对“业务架构”“业务建模”傻傻分不清楚。包括我自己也是。

其实即便分不清这俩概念也不重要，关键的是在需求分析过程中要有业务架构和业务建模的意识--“业务架构”提供从全局视角理解和规划业务， 而“业务建模”则会更加关注业务流程细节和业务规则。

业务架构指导业务建模，缺失了业务建模的业务架构，就犹如大家常说的“空中楼阁”-飘在空中而无法落地。

业务建模负责落地，缺失了业务架构的业务建模，又犹如“盲人摸象”-各自有各自的理解，无全局观。这样就会造成团队“只埋头干活，忘了抬头看路”，完全自嗨，最终无法达成业务价值或提升业务效率。

02 业务建模的目的

业务建模的目的除了能更好地落地“业务架构”以外，还担负着指导应用架构、数据架构的责任。所以，业务建模在需求分析中的角色就是沟通“物理世界”和“数字世界”的“桥梁”，占据着非常重要的地位。

03 传统业务建模手段- UML

在以前“单体架构”的技术背景下，开发工程师主要关注面向对象的分析和设计。因此在业务建模过程中，为了和开发工程师可以更好地沟通，需求分析师会使用UML(Unified Modeling Language)统一建模语言来表示业务分析的成果。

为什么用UML呢？因为UML是可视化的面向对象建模语言，它提供了标准化的建模符号和图形。面向对象、可视化、标准化就是UML风靡软件建模领域的原因。

建模方法：用例分析法/流程分析法

传统的业务建模，大多从用例或流程入手。依据业务类型，选取不同的分析方法。重流程的业务，可以直接分析业务流程。

用例分析法是分析参与者(Actor)在具体业务场景(Scenario)下进行的一系列特定的活动和交互。

用例分析法主要是从Actor所参与的活动为切入点进行分析。用例分析描述除了描述用例的参与者，场景，流程以外，还需要有用例依赖的前置条件，约束，成功保证等其他客观因素。

下图是Alistari Cockburn 的用例模块，供大家参考。

关键交付物：

传统业务建模的用途主要有：

1. 能够可视化的和业务沟通和确认需求
2. 能够用开发能理解切看的懂的原因和开发沟通需求。

因此，为了达成以上目的，以下这些交付物基本就够用了：

• 用例图或用例描述文本
• 泳道业务流程图
• E-R实体关系图
• 状态图(状态矩阵)

04 现代业务建模手段-DDD

随着科学技术的不断发展进步，云计算基础设施能力的成熟，分布式架构越来越多地被应用。因此“微服务”逐渐进入到大家的视野，如何更好地按照业务来合理划分“微服务”便成了大家讨论的话题。原本在2003年就已经提出的DDD理念，随着“微服务”的流行被大家再次拿出来研究。后来居然神奇地发现“DDD+微服务”就是一对绝配CP，彼此互相成就。

建模思想： DDD领域驱动设计

DDD领域驱动设计准确的来讲是一种建模思想，这种建模思想的核心是通过业务的“通用语言”来划分业务的职责和范围，由此能更好的支撑业务。DDD建模的具体实操方法主要有2种：基于场景的事件风暴分析法和四色建模法。这2种方法在下面的DDD领域建模步骤中会介绍。

关键交付物：领域模型

不同的建模实操方法不同，所产生的过程交付物是不同的。但最终产生的领域模型是一样的。如下图，

补充一点：虽然“领域模型”是关键交付物，但是在业务分析过程中产生的其他建模图，比如，用户旅程，业务流程图，业务实体关系图对于后面的数字化建设同样具有非常重要的意义。

05 DDD领域建模的步骤

Step 1. 业务输入- 场景分析法/流程分析法/用例分析法

在分析一个具体业务时，需求分析师需要想清楚分析策略，如何能引导业务方更好更顺畅的输入。只有这样才能够为其从物理世界映射到数字世界的1:1建模过程做好铺垫。

分析的角度其实有很多种：可以从处理的业务场景入手(by scenario)-场景分析法，可以从业务流程入手(by process)-流程分析法，还可以从处理业务的角色入手(by use case)-用例分析法。

不同的项目依据其特点，入手角度是不同的。这个需要依据项目的实际情况，采用适合自己的方式切入。

场景分析法和用例分析法其实有点类似，都是将各种角色在场景下协同作业的活动交互过程用可视化图形表示出来，唯一区别在于梳理场景列表和用例列表的时候，一个是按场景不重不漏，一个是按关键用户不重不漏。

流程分析法适用于项目已经有标准化业务流程(SOP, Standard Operation Process), 直接对流程建模就好。

就我个人的实际项目经验来讲，我喜欢从场景的角度切入 。因为，第一，“场景分析法” 适合绝大多数的项目，比较万能，也符合业务人员的工作思维方式。第二，“场景分析法+MECE原则”能够不重不漏的把某个业务部门处理的业务场景全部罗列出来，不容易遗漏。并不一定要为所有的场景建模，可以挑取其中关键的核心业务场景进行建模即可。

业务输入后的交付物，大致有以下几种可视化图形：

用户旅程：从用户接触产品或服务的时刻一直到完成服务的闭环业务中，用户跟业务人员产生交互的全部过程。在这个过程中，不仅需要体现业务作业环节，而且还需要体现用户用户情感的诉求，用户痛点、痒点。

服务设计蓝图：服务设计蓝图跟用户旅程相似的点是需要体现业务作业环节，不同的是服务设计蓝图更强调服务交互设计的合理性。因此，服务设计蓝图会有交互线，可视交互线和不可视交互线。服务设计蓝图，不仅可以清晰表示完整的业务活动是如何相互协同交互完成的，而且还为优化交互过程提供了依据。

业务流程图（UML/BPMN）：业务流程图大家都比较熟悉了，它主要关注业务流程。按照APQC的PCF框架理论，流程可以分为1-5层。流程的表示法大多都是UML和BPMN表示法。UML通常用泳道流程图来表示，大家估计都用过，这里不赘述了。BPMN(Business Process Model Notation )是由BPMN管理联盟(BPMN Consortium)开发并维护的业务建模语言标准。BPMN是业务流程建模非常专业的一种表示方式，通常用于比较正式的商业沟通，会显得比较高大上一点。个人认为，如果仅是和自家业务部门沟通UML的泳道流程图够用了。下图为BPMN样例图。

Step 2. 领域建模

经过和业务的了解沟通，对业务场景，业务流程有了一定程度的理解和认识后，就可以着手领域建模。领域建模的方法，我现在看到的主要有2种方式：事件风暴法和四色建模法。

事件风暴法，是领域建模最常规的建模方法。

首先，依据Step1中的业务输入，提取事件、命令、和角色。

然后，再依据业务通用语言提取业务实体，聚合根。

最后，依据业务问题空间和解决问题空间来分别划分子域和上下文。

四色建模法，感觉是一种比较小众的领域建模方法。个人认为其优点是，可以围绕时标性对象（moment interval）快速建模；缺点是，适用于规模比较小的项目。首先，按照事件发生的时间顺序寻找时标性对象，即可用来追溯的数据记录。然后，再围绕这些时标性对象来补充产生这些对象的人、事、物。同时，将“人”抽象为参与业务行为的“角色”。这样便可抽象出业务作业过程的业务实体，实体间的关系，以及业务角色。最后，根据抽象出来的业务实体，按照“问题空间”和“解决问题空间”划分子域和限界上下文。

想进一步学习“四色建模法”的童鞋，建议去看一下这两篇thoughtworks出品的文章：

• 《运用四色建模法进行领域分析》，Thoughtworks 徐昊
• 《从“四色建模法”到“限界纸笔建模法”》，Thoughtworks 伍斌

Step 3. 领域模型应用

经过前2步的分析，最后输出领域模型，见下图。领域模型不仅可以用来指导系统全景图的规划，还可以用来指导微服务应用架构的设计和数据架构的设计。