第四章问题空间探索-CSDN博客

本文链接：https://blog.csdn.net/weixin_48540423/article/details/144853572

一旦你了解了问题所在，答案就变得相对简单了。我从中得出结论:我们应该立志去增强人类的自我意识，这样才能更好地去理解问题所在。-一埃隆·马斯克，《埃隆·马斯克的冒险人生》

在项目之初，问题空间对我们而言是完全未知的。在项目开发的早期，我们应在宏观层次对问题空间做一次全方位的梳理和分析，这就是领域驱动设计统一过程的全局分析阶段。

全局分析的5w模型

既要做到空间的规划，又要融入场景的体验，最佳方法就是通过5W模型展开对问题空间的探索。

要清晰地描述一件事情，可以遵循6W要素的情景叙述法:谁(Who)基于什么原因(Why)在什么地点(Where)什么时候(When)做了什么事情(What)是怎么做到的(how)。
6W要素中的前5个要素皆与问题空间需要探索的
内容存在对应关系。

Who:利益相关者。
Why:系统愿景。
Where:系统范围。
When:业务流程。
What:业务服务。

全局分析的5W模型包含价值需求和业务需求，它们共同组成了目标系统的问题空间。

价值需求需要从系统价值的角度进行分析获得。

没有价值，系统就没有开发的必要，而价值一定是为人提供的。不同角色的人对于该系统的期望并不同，牵涉到的利益也不相同，这也是将系统的参与者称为“利益相关者”(stakeholder)的原因。

利益相关者是团队进行需求调研的主要访谈对象。在综合利益相关者提出的各种价值之后,我们需要对这些价值进行提炼和概括并将所有利益相关者关注的主要价值统一到一个方向上，如此就明确了系统的愿景。确定了系统的愿景，就可将其作为业务目标的衡量标准，并通过分析目标系统的当前状态与未来状态，确定目标系统的范围。

利益相关者、系统愿景和系统范围共同组成了目标系统的价值需求，分属于5W模型中的Who模型、Why模型与Where模型。

业务需求由动态的业务流程与静态的业务场景、业务服务构成。业务服务是全局分析阶段获得的基本业务单元

业务服务描述了目标系统到底做什么，即目标系统提供的业务功能，属于5W模型中的What模型
如果某个业务服务为另外一些提供了核心价值的业务服务提供支撑，具有辅助价值却又不具有通用意义，应划入支撑子领域。
如果某个业务服务没有鲜明的领域特征不具有个性特征的通用功能，但又不可缺少，应划入通用子领域。
如果某个业务服务提供了目标系统的核心价值，或者具有不可替代的作用，满足了最重要的利益相关者的价值需求，应划入核心子领域。

多个角色在不同阶段参与到业务流程中，所执行的所有业务行为都是为完成业务价值，每个业务流程都体现了一个业务价值。将一个完整的业务流程划分为多个段，每个阶段都完成自己的业务目标，在业务目标的指导下将业务流程划分为多个业务场景，形成对业务流程的纵向切割，组成多个角色执行业务服务的时空背景。每个角色在该时空背景下与目标系统的一次完整功能交互，都是为了获得服务价值，这就是业务场景下的一个业务服务。

整个流程由处于不同时间点的执行步骤构成，具有时间属性，属于5W模型中的When模型。不同业务服务的重要性并不相同。核心子领域、通用子领域和支撑子领域共同构成了整个目标系统的问题空间。

高效沟通

全局分析的5W模型撑起了精准获得问题空间的整个骨架，在价值需求分析与业务需求分析过程中，需要引入不同的方法与实践帮助分析者探索问题空间不同层次的模型要素。运用正确的方法、遵循正确的过程是正确做事的原则，但对于全局分析这样一个探索问题空间的特殊阶段，还离不开业务分析师与利益相关者的高效沟通，它是探索问题空间的前提
在探索问题空间时，业务分析师不仅要竖起双耳聆听各个利益相关者的“心声”，还要擦亮眼睛观察用户的操作行为，听其言观其行，细心发掘需求。业务分析师必须是一名循循善诱的引导者，与利益相关者共同组成一个密不可分的利益共同体，共同培育需求。发掘和培育需求的过程需要双向的沟通、反馈，更要达成对领域知识理解上的共识。每个人心中都对原始需求有自己的理解，如果没有正确的沟通交流方式，团队达成的所谓“需求一致”不过是一种假象罢了。因此，高效沟通的基础是达成共识。

达成共识

每个人获得的信息不同、知识背景不同，各自的角色不同又导致我们设想的上下文也不相同。因为我们对客户需求的理解存在3个方向的偏差:

我们从利益相关者了解到的需求并非最终用户的需求。
若无有效的沟通方式，需求的理解偏差会导致结果与预期大相径庭。
理解到的需求并没有揭示完整的领域知识，导致领域建模与设计出现认知偏差。

通过可视化的方式展现出来。绘图、使用便签、编写用户故事或测试用例，都是重要的辅助手段。明确了差异，就可以利用各自掌握的知识互补不足去掉有余，最终得到大家都一致认可的需求形成统一的认知模型。

统一语言

达成共识的目的是确定目标系统的统一语言。获得统一语言就是在全局(ubiquitous language)分析过程中不断达成共识的过程，即团队中各个角色就系统愿景、范围和业务需求达成一致，并通过一种直观的形式体现出来，以作为沟通与协作的基础，当我们建立了符合整个团队皆认同的一套统一语言后，就可以在此基础上寻找正确的领域概念，为建立领域模型提供重要参考。利用统一语言还可以对领域模型做完整性检查，保证团队中的每位成员共享相同的领域知识。

形成统一的领域术语,尤其是基于模型的语言概念,是让沟通达成一致的前提。
维护领域术语表，建议给出对应的英文术语。

领域行为描述可以视为领域术语甄别的一种延伸。
在描述领域行为时，需要满足以下要求:
从领域的角度而非实现角度描述领域行为。
若涉及领域术语，必须遵循术语表的规范。
强调动词的精确性，符合业务动作在该领域的合理性。
要突出与领域行为有关的领域概念。

在明确统一语言时，需要“大声说出来”，清晰地表达出统一语言蕴含的领域概念。对用疑问的地方要及时说出来。

建立统一语言不限于全局分析阶段，实际上它贯穿了整个领域驱动设计统一过程

在全局分析阶段，所有参与价值需求分析与业务需求分析的领域专家和开发团
队成员都通过统一语言来就业务知识达成共识，以此来探索问题空间:在架构映射阶段，需要统一语言来规范对业务服务的描述，才能通过语义相关性与功能相关性识别限界上下文;到了领域建模阶段，领域模型与统一语言的关系更是成为一种相辅相成的关系，统一语言指导着领域建模，而领域建模的成果又反过来丰富了统一语言，确保了领域模型与统一语言的一致性。

高效协作

要让全局分析过程“充满有趣的互动”，就要以视觉方式引导团队，召开视觉会议来促进团队的高效沟通。
这种视觉会议具有更强的参与感，在互动过程中提高了参与者的投入意识；共同协作创造的全景图，体现了团队整体的全景思维:"创建了更容易记忆的媒介，极大地增加了群体记忆

商业模式画布

商业模式画布由9个板块构成。

客户细分(customersegments):企业所服务的一个或多个客户分类群体，可以是企业组织、最终用户等。
价值主张(value propositions):通过价值主张来解决客户难题和满足客户需求，为客户提供有价值的服务。
渠道通路(channels):通过沟通、分销和销售渠道向客户传递价值主张，即企业将销售的商品或服务交付给客户的方式。
客户关系(customer relationships):在每一个客户细分市场建立和维护企业与客户之间的关系。
收益来源(revenue streams):通过成功提供给客户的价值主张获得营业收入，是企业的盈利模式。
核心资源(key resources):企业最重要的资产，也是保证企业保持竞争力的关键，这些资源包括人力和物力。
关键业务(key activities):通过执行一些关键业务活动,运转企业的商业模式。
重要合作(key partnership):需要从企业外部获得资源中就需要寻求合作伙伴。
成本结构(cost structure):该商业模式要获得成功所引发的成本构成。

这一方法适合分析师通过召集团队进行头脑风暴，并以画布的可视化方式引导大家一起梳理目标系
统(当然也可以说是产品)的价值需求。

业务流程图

业务流程图(transaction flow diagram, TFD)善于表现业务流程。它通过使用诸如任务流程图、泳道图等图形形象地描述真实世界中各种业务流程的执行步骤与处理过程。在绘制业务流程图时,尽量使用标准的可视化符号如此就可以形成一种交流的统一语言。常用的流程图符号如图所示。

泳道图((swimlane)是最为常用的业务流程图表现形式，它能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。泳道图通过两个维度分别表现业务流程的划分阶段与参与部门(或岗位)，分别称为阶段维度与部门/岗位维度，如图所示。

绘制业务流程图时，为保证业务流程的清晰度，倘若一个主业务流程中还牵涉到多个嵌套的子流程，可以使用子流程符号来“封装”子流程的执行步骤细节。

服务蓝图

服务蓝图是用于服务设计的主要工具，相较于用户体验地图或用户旅程，它以更加全面的视角展现了客户
与前台员工、前台员工与后台员工、后台员工与内部支持者(包括支持部门或支持系统)之间的协作。因此
服务蓝图能够全方位地展现具有完整业务价值的业务流程。如果将一个业务流程理解为是对客户提供的服务
那么一个服务蓝图就对应了一个业务流程。

服务蓝图通过3条分界线(即可见性分界线、交互分界线、内部交互分界线)将一个完整的业务流程分割为不同参与角色执行业务活动的不同区域。分割出来的各个区域代表了不同角色的活动类型，也体现了不同的观察视图，在保证业务流程全貌的基础上清晰地体现了参与角色、活动类型、活动阶段的不同特征。服务蓝图的可视化模板
这3条分界线清晰地展现了各个角色的职责边界形成了以下4个活动区域。

客户活动(customer actions):客户为了满足自己的服务要求执行的操作。
前台员工活动(onstageemployee actions):客户能够看到的前台员工操作的行为和步骤。
后台员工活动(backstageemployee actions):发生在客户看不到的后台，支持前台的后台员工活动。
支持过程(support process):内部支持者为前台、后台员工履行服务提供支持。

在运用服务蓝图展现一个完整的业务流程之前，团队需要事先了解服务企业的组织结构和员工角色，这些角色与客户一起共同组成参与服务蓝图的角色。绘制服务蓝图需要团队与提供服务的组织成员共同协作，协作的过程就是将业务流程逐步呈现的过程,具体步骤如下

在空白的白板上画出交互分界线，在左侧对应位置分别贴上当前业务流程的客户角色:
从客户角度描绘整个业务流程中为客户提供服务的过程，写在即时贴上，按照时间顺序依次贴在交互分界线的上方:
识别出与客户活动存在互动关系的前台员工活动，写在即时贴上并标记出前台员工角色，贴在对应活动下方，用带箭头的实线表示活动之间的调用关系箭头方向体现了流程方向;
画出可见性分界线，在左侧对应位置贴上后台员工角色;
识别出支持前台员工活动的后台员工活动写在即时贴上并标记出后台员工角色，贴在对应活动下方，用带箭头的虚线表示支持关系，箭头指向被支持的活动;
画出内部交互分界线:
识别出支持各类活动的支持过程，并标记出内部支持者角色，用带箭头的虚线表示支持关系，箭头指向被支持的活动。

服务蓝图是展现业务流程的全景图。无论是线上活动还是线下活动,也不管是顺序调用还是等待消息通知，只要是该业务流程的执行步骤，都需要在服务蓝图中体现出来。服务蓝图是真实世界业务流程的真实体现。

用例图

用例(use case)是对一系列活动(包括活动变体)的描述;主体(subject)执行并产生可观察的有价值的结果，并将结果返回给参与者(actor)。

如果将整个组织作为用例的主体，参与者就应该是组织外的角色，用例表现的就是该角色与组织之间的一次交互此时的用例称为业务用例，代表了组织的本质价值；
如果将目标系统作为用例的主体，参与者就变成了目标系统外的角色(人或者外部系统)，此时的用例称为系统用例，表现的是角色与目标系统之间的一次交互，通过这种交互，参与者获得了目标系统提供的业务价值。
用例的主体体现了边界的大小与层次，它决定了参与者的角色、价值的层次以及参与者和主体之间的交互形式。通过用例图对主体行为进行可视化建模。

一个用例图由火柴棍人表示的参与者、椭圆形表示的用例、矩形表示的主体边界和连线表示的关系共同构成。如果还需要表现一个用例内部的执行步骤，还可以有用例的包含用例、扩展用例，以及可能具有的泛化关系(参与者的泛化或用例的泛化)，如图所示。

在这里插入图片描述

用例名是领域知识的呈现，更是统一语言的有效输入。用例名应使用动词短语，描述时需要字斟句酌，把
握每一个动词和名词的精确表达。动词是领域行为的体现，名词是领域概念的象征，这些行为与概念就能再借助领域模型传递给设计模型，最终通过可读性强的代码来体现。

事件风暴

Alberto Brandolini提出的事件风暴(参见附录B)是以一种工作坊形式对复杂业务领域进行探索的高效协
作方法。它对业务探索的改进体现在两点

以事件为核心驱动力对业务开展探索。
强调可视化的互动，更好地调动所有参与者共同对业务展开探索。

白色画卷纸、胶带纸条、各种颜色的即时贴以及马克笔成了开展事件风暴的利器

用于领域驱动设计的事件风暴有以下两个层次。

探索业务全景:属于宏观层次，寻找业务流程产生的事件，形成一个全景的事件流。
领域分析建模:属于设计层次，通过探索业务全景获得中的事件流，围绕着事件获得领域分析模型。

学习循环

商业模式画布、服务蓝图、事件风暴之类的协作方法都是视觉会议形式的协作方法。这种协作方法之所以能够促进团队高效协作，是因为它使得每个与会者都能充分参与，形成一种良性的群体思考过程，这一过程就是学习循环。

学习循环“开始于对意图和任务焦点的想象，接着是探索与投入，然后是思考和发现模式，最后是决定行动与应用。这些步骤整合了我们认知的知觉、情绪、思考和感觉部分。”lsm探索问题空间本身就是从未知到已知的学习过程，视觉会议协作方式对传统协作方式最大的变革在于它将原本属于个人的学习过程转变为群体共同工作的学习过程。协作的难能可贵之处就是要向着一个共同目标以正确而高效的步伐迈进，不止如此，在这个过程中还需要创意与见解形成脑力的激荡。从想象开始，通过视觉化吸引团队投入，然后用视觉思维呈现每个人的想法，最后就可以收获探索的结果，以决定下一步的行动。