在领域驱动设计统一过程中的全局分析阶段，我们通过价值需求分析识别出相关利益者、明确系统愿景和确认系统范围之后，需要进一步进行业务需求分析，如果说价值需求分析是纲要，那么业务需求分析就是业务系统的具体内容了，在业务需求分析中，可以从以下3个层次进行，分别是：
① 业务流程：业务系统对外提供的业务能力的完整过程。
② 业务场景：在业务流程流程上某一个分支流程，业务系统对外提供的业务能力可能存在多个应用场景。
③ 业务服务：实现业务场景的业务功能。

这三个层次的整体关系如下：

一、业务流程

业务流程是系统对外提供业务能力的一个完整的过程，比如短信平台对外提供短信发送能力，那么短信发送的涉及到的内部所有环节（编辑短信、内容校验、提交到运营商、短信下发、接收下发结果）所组成的完整过程就是业务流程。

我们在描述一个业务流程时，通常会使用业务流程图来辅助说明，一图胜千言，通过可视化的方式展示更容易让人明白，那么常用的业务流程图包括泳道图、服务蓝图等，比如在上面提到的短信平台的短信发送业务流程，我们可以用泳道图来说明。

从上面的泳道图，我们可以比较清晰的了解短信发送的一个完整过程，这里面涉及到用户、短信平台、运营商等不同的角色，以及每个角色在这个业务流程中所处理的事情。但通常在短信平台内容通常由不同的角色来处理不同的事情，比如短信审核由系统内部处理，解释发送结果由客服人员处理，那么需要在一个流程图中展示不同角色的工作职责，可以用服务蓝图来呈现。

二、业务场景

通常一个完整的业务流程包含多个分支流程，每个分支流程就是一个业务场景，业务场景以用户为中心，采用一种身临其境的方式体验用户角色的操作行为，通常一个完整的业务场景包括5要素，分别为角色（Who）、时间（When）、空间（Where）、活动（What）和业务目标（Why），也称之为5W模型。例如以上面短信发送为例子，可以这样描述业务场景：我（Who）在短信平台上（Where）编辑短信后（What），点击发送按钮（When），平台告知我短信内容不合法，包含了敏感词：XXX，因此发送不了短信(Why)。

三、 业务服务

1、什么是业务服务？

业务服务是角色主动向目标系统发起服务请求完成的一次完整的功能交互，体现了服务价值的业务行为。这里可以看出，业务服务是一种业务行为，但并不是所有的业务行为都是业务服务，那么如何识别业务服务呢？需要从服务价值、角色和执行序列来判断。

（1）服务价值

服务价值是要站在目标系统的角度，思考它能为执行业务服务的角色提供什么样的服务。比如上面短信平台的“短信发送”就是一个业务服务，它能够为客户提供短信发送的服务，而“编辑短信”只是业务行为，并不是业务服务，它不是一个完整的功能交互。

（2）角色

一个业务服务必须有一个角色作为发起者，它会触发业务请求，通常包括用户、策略或者伴生系统。也就是说业务服务必须是对外的，由外部触发而提供的服务，系统内部提供的功能服务不能成为业务服务。

（3）执行序列

业务服务的执行序列意味着执行的所有步骤都是连续且不可中断的，如此才能完成一次完整的功能交互，比如上面短信平台的服务蓝图中，客户侧发送短信需要经过的流程：编辑短信、短信发送、查看发送结果，我们一个个来判断这3个业务行为是否为业务服务。
① 编辑短信：如果用户在短信平台管理页面上发送短信，则需要编辑短信，如果是通过API接口发送，则不需要，因此“编辑短信”可选，它不是业务服务。
② 短信发送：无论是哪种途径，都需要“短信发送”这个业务行为，因此它是业务服务。
③ 查看发送结果：判断它是否为业务服务，就是拿掉它，看看对结果有没有影响，很明显，不查看发送结果，对于“发送短信”来说没有任何影响，因此它也不是业务服务，只是流程中的一个执行步骤而已。

2、业务服务如何呈现？

（1）业务服务图

可以以业务场景单位，为每一个业务场景绘制一张用例图，用例图内部的椭圆图形对应一个个业务服务。

（2）业务服务的规约

用例图是对业务场景中所有业务服务的一种全局性展示，对于具体的每个业务服务的描述，需要用到业务服务规约，具体的展示方式如下:

组成元素	说明
服务编号	标记业务服务的唯一编号
服务名	动词短语形式的服务名
服务描述	作为<角色>我想要<服务功能>以便<服务价值>
触发事件	触发该业务服务的事件，如按钮点击、策略规则的触发或接受指定的消息等。
基础流程	用于表现业务服务的主流程，即执行成功的业务场景
替代流程	用于表现业务服务的扩展流程，即执行失败的业务场景
验收标准	一系列可以接受的条件或者业务规则，以要点形式列举

四、子领域

软件系统的建设与现实生活中的很多东西的生产本质是类似的，比如汽车的生产，从车身、底盘、发动机到车轮不会一体化生产，而且采用各自独立生产最后组装成一辆汽车的方式，这样更高效灵活。一个大型软件系统的建设也是类似原理，面对庞大的业务需求，通常会常用分而治之的方法对业务需求进行划分，形成范围更小更聚焦的业务单元，我们把这个业务单元称之为子领域。

1、子领域元模型

根据核心问题和次要问题，子领域可定义为核心子领域、通用子领域和支撑子领域。核心子领域是目标系统最为核心的业务资产，体现了目标系统的核心价值；通用子领域所描述的是目标系统通用问题，比如用户管理、权限管理等；而支撑子领域所描述的是目标系统的辅助问题，比如消息通知等。比如我们现在建设一个通信平台，通信的渠道包括短信、5G消息、微信、邮件，那么我们可以把最核心业务定义为核心子领域，比如短信子领域、5G消息子领域、微信子领域和邮件子领域，而把系统通用功能，比如用户管理和权限管理定义为通用子领域，比如用户子领域和权限子领域，最后系统需要用到的辅助功能定义为支撑子领域，比如通知子领域等。那么这里就有问题了，我们怎么识别出目标通哪些是核心子领域、哪些是通用子领域呢？

2、识别子领域

对于目标系统的子领域的识别，可以通过功能分类策略，包括如下几种；
（1）业务职能：当目标系统运用于企业的生产和管理时，与目标系统业务有关的职能部门往往会影响目标系统的子领域划分，并形成一个简单的映射管理。比如校园管理系统，按照学校的业务职能划分，可以获得教务、学生管理、科研、财务等子领域，这些对应学校的职能部门，如教务处、学生处、科研处以及财务处。

（2）业务产品：当目标系统为客户提供诸多具有业务价值的产品时，可以按照产品的内容和方向进行子领域划分。比如上面提供的通信平台，可以根据平台的通道渠道（短信、5G消息、微信、邮件）获得短信子领域、5G消息子领域、微信子领域和邮件子领域。

（3）业务环节：对贯穿目标系统的核心业务流程进行阶段划分，然后按照划分出来的每个环境确定子领域。比如对于电商平台，最核心的业务流程是买家购买商品的业务流程，该流程可以划分多个不同的环节：浏览商品、添加购物车、下订单、支付、配送等，可以获得对应环节的子领域，分别为商品子领域、购物车子领域、订单子领域、支付子领域以及物流子领域等。

（4）业务概念：捕捉目标系统中一目了然的业务概念，将其作为子领域。比如音乐在线平台，根据歌手、电台、直播、MV等业务概念，可以获取对应的子领域。

在子领域识别的基础上，根据领域愿景，也就是目标系统的核心价值进而识别出核心子领域、通用子领域和支撑子领域。

3、子领域映射图

一图胜千言，通过映射图的形式对业务系统子领域进行全局性呈现，然后目标系统建设的业务范围更加一目了然。通常可以用一个大椭圆代表整个目标系统，然后再在椭圆里划分不同区域代表子领域。