前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、全局分析的 5W 模型

要清晰的描述一件事情，可以遵循 5w 要素的情景叙述法，谁 who 基于什么原因why，在什么地方where，是什么时候wnen，做了什么事情what，怎么做到的 how。5 要素中的前五个与问题空间需要探索的内容存在对应关系

5w	说明
who	利益相关者
why	系统元愿景
where	系统范围
when	业务流程
what	业务服务，描述到底做了什么

价值需求需要从系统价值的角度进行分析获取，没有价值，系统就没有开发的必要，价值一定是人为提供的，不同角色的人对于该系统的期望并不相同，牵扯到的利益也不同。这就是系统的利益相关者。 我们需要对利益相关者提出的各种价值进行提炼概括，进而明确愿景。通过分析目前系统的当前状态和未来状态，确定目前系统的范围。利益相关者（who），系统愿景why，系统范围where共同组成了目标系统的价值需求。

业务需求由动态的业务流程和静态的业务场景和业务服务构成，每个业务路程都体现了一个业务价值，多个角色在不同阶段参与到业务流程中。整个流程由处于不同时间点的执行步揍构成，具有时间属性，属于 5w 中的 when，每个角色在该时空背景下与目标系统的一次完整服功能交互都是为了获得服务价值，这就是业务场景喜爱的一个服务服务。业务服务是全局分析阶段下获得的基本业务单元，业务服务描述了目标系统到底做了什么，即目标系统提供的业务功能，属于 5w 中的 what

二、高效沟通

全局分析的 5w 模型撑起了精准获得问题的空间的整个骨架，但这离不开业务分析师和利益相关者的高效沟通。

1、达成共识

达成共识的目的是确定目标系统的统一语言，获得统一语言就是在全局分析的过程中不断达成共识的过程。使用统一语言可以帮我们参与讨论的利益相关者，领域专家，开发团队拉到同一个维度空间进行讨论，没有达成共识，就是鸡同鸭讲。毫无沟通效率。

2、统一语言

一单确定了统一语言，最终都可以通过相同的术语清晰准确地定义和表达领域知识

形成统一的领域术语，尤其是基于模型的语言概念，是让沟通达成一致的前提。业务人员，开发人员等存在知识差异，开发人员更熟悉代码细节，业务人员更熟悉业务。两种角色直接的交流就好像两种不同语音的人直接交流。必然磕磕绊绊。从需求中提炼统一语言，就是在两种语言直接进行正确翻译的过程

三、高效协作

一个只靠文字组成的文档进行纸面交流，如能成为一个高效协作的团队。一图胜千言。

1、商业模式画布

商业画布共有9个方格组成，每一个方格里面都涵盖着成千上万种的可能性和替代方案，以画布的可视化方式引导大家一起梳理目标系统的价值需求

方格	理解	说明
客户细分	你想帮助谁？	找出你的目标用户用来描述一个企业想要接触和服务的不同人群或组织
价值主张	你提供的价值是什么？	你所提供的产品或服务。用来描绘为特定客户细分创造价值的系列产品和服务；
用户获取渠道	你怎么触达客户？	分销路径及商铺，用来描绘公司是如何沟通接触其客户细分而传递其价值主张；
客户关系	你与客户怎么样互动？	你想同目标用户建立怎样的关系，用来描绘公司与特定客户细分群体建立的关系类型；
收入来源	你能创造哪些收益？	用来描绘公司从每个客户群体中获取的现金收入，是企业的盈利模式
核心资源	你需要什么？	资金、人才，用来描绘让商业模式有效运转所必需的最重要的因素；
关键业务	你的核心业务是什么？	执行一些关键业务活动，运转企业的商业模式
重要伙伴	谁能帮助你	让商业模式有效运作所需的供应商与合作伙伴的网络。
成本结构	你的成本有哪些	运营一个商业模式所引发的所有成本。

2、业务流程图

业务流程图善于表现业务流程，在绘制流程图的时候，尽量使用标准的可视化符号。如此就可以形成交流的统一语言。如泳道图，任务流程图

想要画好流程图，需要遵循一些的设计规范，掌握一些绘图技巧。例如符号规范、逻辑规范、结构规范、路径规范等等设计规范，比如流程图的绘制顺序：一般遵循，应从上至下，从左到到右的顺序，这样更便于阅读和理解。

1）流程图结构

a、顺序结构

b、分支结构

c、循环结构

2）流程图组件

a、开始、结束

开始组件：作为整个流程的入口，只允许引出连线，不允许引入连线。

结束组件：作为整个流程的，只允许引出连线，不允许引入连线。

b、分支判断

c、调用外部数据，引用外部数据

d、存储数据，输出存储数据

e、流程图中涉及的文档

f、手动输入处理

表示手动输入处理。如手动输入用户名和密码。或者手动录入数据等等。

g、子流程

预先定义的子流程。引用某一预先定义的流程进行处理。如示例，汽车空调加工子流程。

3、服务蓝图

服务蓝图不是记录用户体验。而是以用户的体验作为起点，揭露组织如何支持该旅程 。服务蓝图能够全方位展现具有完整业务价值，如果将一个业务流程是对客户提供的服务，那么一个服务蓝图就成对应了一个业务流程，服务蓝图是真实世界业务流程的真实实现，

服务行为由三条分界线构成：互动分割线、可视边界线和内部支持线；分别描述前台服务面对消费者，后台服务支持前台，公司系统支持前后台的服务逻辑。它不仅包括横向的消费者服务过程，还包括纵向的内部协作，是描绘整个服务前、中、后台构成的全景图。

1）外卖平台服务蓝图

用户行为是通过某外卖平台订购外卖、配送、收到外卖、用餐后完成整个订单流程，服务的后台交互包括了订单处理、优惠活动、时间地点等。

2）快递服务蓝图

3）用户手机选择餐厅

4、用例图

用例图是编写需求说明时经常用到的需求表达方式，用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。它主要由三部分组成：参与者、用例、参与者与用例之间的关系。

组成部分	说明
参与者	不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等
用例	是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
关系	参与者与用例之间的关系主要包括关联、归纳、包含、拓展

1）关联关系

关系说明：表示参与者与用例之间的关系

表示方法：带箭头的实线，箭头指向用例。

举例说明：用户登录系统

2）归纳关系

关系说明：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关。

表示方法：带空心箭头的实线，箭头指向被泛化（被继承）的用例，即基础用例/父用例。（注意：泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程，继承是从上到下，从一般到特殊的过程。）

举例说明：业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

3）包含关系

关系说明：表示用例与用例之间的关系，其中一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为。

表示方法：虚线箭头+«include»字样，箭头指向被包含的用

举例说明：用户在账号登录过程中，包括输入账号、输入密码、确认登录等操作

4）拓展关系

关系说明：表示用例与用例之间的关系；用于拓展用例对基础用例的增强；拓展用例是在特定条件出现时，才会被执行的用例。

表示方法：虚线箭头+«extend»字样，箭头指向被扩展的用例（即基础用例）

举例说明：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述

5、事件风暴

事件风暴是一种敏捷的、协作式的业务分析和设计方法，由 Alberto Brandolini 提出。它聚焦于识别业务流程中的事件，这些事件代表业务状态的重要变化。通过头脑风暴，团队成员共同梳理出系统中发生的事件、触发事件的命令、事件涉及的聚合（业务对象）以及相关的角色和职责。这种方法有助于团队成员从不同角度理解业务，打破沟通壁垒，快速建立统一的业务认知，为后续的系统设计和开发提供坚实的基础。

主持人必须是 DDD 从业者才能指导小组走向完整的模型。包括非技术产品所有者在内的每个人都可以参与对领域的理解和建模。整个团队了解域越好，软件实施越有可能反映域，这是 DDD 的主要目的。以下是事件风暴如何运作

1）运作

1. 场景：以电商平台中用户领取优惠券为例，为你展示领取驱动建模和事件风暴的完整运用：
2. 参与人员：产品经理、开发人员、测试人员、业务分析师、运营人员。
3. 准备材料：大白板、不同颜色的便签纸、马克笔。

a、识别事件

在事件风暴中，明确所有与 “领取” 相关的事件，例如用户领取任务、领取商品、领取优惠券等。每个领取事件都可能是业务流程中的关键节点，对这些事件进行详细分析，确定事件发生的前置条件、后置结果以及相关的数据变化。

所有参会人员在便签纸上写下自己能想到的与用户领取优惠券相关的事件，一个事件写一张便签纸。例如：

• 用户进入优惠券领取页面
• 用户点击领取按钮
• 系统验证用户领取资格
• 系统生成优惠券发放记录
• 优惠券发放到用户账户
• 用户查看账户中的优惠券
• 用户使用优惠券下单

• 系统扣除优惠券

• 将这些便签纸随意贴在大白板上。

b、整理和分类事件

以领取事件为核心，梳理出完整的领取流程。通过事件风暴的讨论，明确每个领取事件前后的其他相关事件，形成一个连贯的业务流程。例如，在领取任务的流程中，可能涉及任务发布、任务分配、用户领取、任务执行、任务完成等一系列事件。

• 大家一起讨论便签纸上的事件，按照时间顺序和业务逻辑进行排列。
• 把相关的事件进行分组，比如分为领取前、领取中、领取后、使用时这几个阶段。
• 例如：
  • 领取前：用户进入优惠券领取页面
  • 领取中：用户点击领取按钮、系统验证用户领取资格、系统生成优惠券发放记录、优惠券发放到用户账户
  • 领取后：用户查看账户中的优惠券
  • 使用时：用户使用优惠券下单、系统扣除优惠券

c、识别聚合和命令：

在确定领取事件和流程后，进一步识别与领取相关的聚合（业务对象）和命令。聚合是业务领域中紧密相关的数据和行为的集合，例如任务聚合可能包含任务的基本信息、任务状态、领取人等；命令则是触发事件的操作，如 “提交领取请求” 命令会触发 “用户领取任务” 事件。

• 命令

  ：找出触发事件的操作，写在黄色便签纸上。例如：

  • 用户点击领取按钮（触发 “用户点击领取按钮” 事件）
  • 用户提交订单（触发 “用户使用优惠券下单” 事件）

• 聚合

  ：确定与事件相关的核心业务对象，写在蓝色便签纸上。例如：

  • 优惠券（贯穿整个领取和使用流程）
  • 用户账户（关联优惠券的发放和使用）
  • 订单（在使用优惠券下单时相关）

• 将命令和聚合便签纸贴在对应的事件旁边。

d、明确角色和职责：

通过事件风暴，明确在领取驱动的业务流程中各个角色的职责。不同角色（如管理员、用户、系统等）在领取事件和相关流程中扮演不同的角色，承担不同的职责。例如，管理员负责发布任务，用户负责领取和执行任务，系统负责记录和更新任务状态等。

• 讨论每个事件、命令和聚合涉及的角色，用绿色便签纸写下角色名称及职责。例如：
  • 用户：进入领取页面、点击领取按钮、查看账户优惠券、使用优惠券下单
  • 系统：验证用户领取资格、生成优惠券发放记录、发放优惠券到用户账户、扣除优惠券
  • 运营人员：创建和配置优惠券规则（虽然不在直接的领取流程事件中，但对整个业务有重要影响）
• 将角色及职责便签纸贴在大白板上相关位置。

e、领取驱动建模

1. 业务流程梳理
   • 根据事件风暴的结果，绘制详细的业务流程图。从用户进入优惠券领取页面开始，到最终使用优惠券下单完成，展示整个流程走向，包括每个步骤的条件判断（如领取资格验证）和不同情况下的分支流程。
2. 数据模型设计
   • 基于识别出的聚合，设计数据模型。例如，优惠券的数据表可能包含优惠券 ID、优惠券类型、面值、有效期、领取条件、发放状态等字段；用户账户表关联优惠券字段，记录用户已领取的优惠券；订单表则记录使用优惠券的订单信息及优惠金额等。
3. 系统功能设计
   • 根据业务流程和数据模型，确定系统需要具备的功能模块。如优惠券领取模块，包含领取页面展示、领取按钮交互、领取资格验证逻辑；用户账户模块，用于显示和管理用户的优惠券；订单模块，实现优惠券在下单时的抵扣功能。
4. 交互设计
   • 设计用户与系统的交互流程。比如用户在领取页面的操作引导，领取成功或失败的提示方式；查看账户优惠券的界面布局；使用优惠券下单时的操作步骤和提示信息等，确保用户体验的流畅性和友好性。通过这样完整的事件风暴和领取驱动建模过程，能够全面、深入地理解电商平台中用户领取优惠券这一业务场景，为后续的系统开发、测试和上线运营奠定坚实基础 。

2）事件风暴能解决的问题

1、当软件系统需要进行跨部门的协作与对齐时，能帮助所有 stakeholder 看到整个系统的全貌、让技术和业务在同一个问题上进行讨论、发现有价值的问题、定义与明确各 stakeholder 的职责、发现逻辑漏洞、划分系统上下文、统一语言。

2、当软件系统开始研发之前，能帮助研发团队所有人看到系统的全貌或者一个上下文的全貌、协助进行业务建模，统一语言、非常适合项目研发的 kickoff 。

3、当有新人入职时，能帮助新人快速的学习系统的全貌、边界以及统一的语言。

3）事件风暴不能解决所有问题

1、不能解决所有的沟通协作问题

2、不能解决 Why 的问题，更适合解决 How 的问题

3、不适合用做底层技术的讨论