领域驱动设计全局分析_3_业务需求分析
前言
Github:https://github.com/HealerJean
一、概念
从需求的层次来看,业务需求根据价值和目标可以分为如下3个层次
层次 | 说明 |
---|---|
业务流程 | 体现一个完整的业务价值 |
业务场景 | “在一个阶段内共同满足多个角色的业务目标,也可认为是该阶段的里程碑目标 |
业务服务 | 业务系统为一个角色提供服务价值 |
二、业务流程
1、业务流程的关键点
识别业务流程的关键点:完整和边界
⬤ 一个有效的业务路程必须是完整的,发起一个服务流程必有其因,也有结果(业务价值)
⬤ 针对目标系统识别业务流程,就需要结合系统范围确定业务流程的边界
2、业务流程的分类
1)业务流程特征
从业务流程特征来看,可以分为主业务流程,变体业务流程,支撑业务流程
业务流程特征 | 说明 |
---|---|
主线流程 | 核心业务流程,如电商的购物流程 |
支线流程 | 支撑业务流畅进行,一些附加服务的流程,如客户咨询、客户投诉流程等。 |
变体流程 | 核心业务下的独立变体,即非常规的流程,如电商的退换货流程、酒店的换房续房流程等。 |
2)业务流程者发起
从业务流程发起者来看,分为外部业务流程、内部业务流程、管理业务路程
业务流程者发起 | 说明 |
---|---|
外部业务流程 | 外部业务流程往往由组织外用户(客户)发起 |
内部业务流程 | 内部业务流程往往由组织内用户(员工)发起 |
管理业务流程 | 管理业务流程由负责管理职能的业务部门人员主动发起的服务请求,主要用于实现控制、监督、管理、审批等管理意图的流程 |
3、业务流程的呈现
⬤ 呈现业务流程最直接的方式就是运用业务流程图,可以帮助受众快速了解业务本身的运作方式,明确业务规则。
⬤ 如果是对于一个复杂的业务流程既要从全局视角体现完整性,又要准确识别边界,可以用服务蓝图来呈现,服务蓝图能够全方位展现具有完整业务价值
三、业务场景
“场景就是角色之间为了实现共同的业务目标进行互动的时空背景,通过角色在特定时间、空间内执行的活动来推动情景的发展,形成角色与目标系统之间的体验与互动”
1、业务场景的5w模型
“角色(Who)、时间(When)、空间(Where)、活动(What)和业务目标(Why)”
“一个业务场景中,所有角色执行的活动都是为了满足一个共同的业务目标,这是确定业务场景的关键”
只要按照阶段性的业务目标划分业务流程,就可以获得业务场景,划分业务场景时,活动是业务流程的各个执行步揍,不能直接映射为业务服务,业务服务是组成业务需求的基本单元,对他的识别是业务需求分析阶段的关键
四、业务服务
业务服务是角色主动向目前系统发起服务请求完成的一次完整的功能交互,体现了服务价值的业务行为。以下3个关键要素缺一不可
1、3个关键
1)服务价值
服务价值:站在目标系统的角度,能为执行业务服务的角色提供什么样的价值。“提交订单”是一个具有服务价值的业务服务,如果客户不执行该业务服务,整个购买流程就无法完成;验证订单虽然提供了验证订单有效性的价值,但它对客户而言却是隐藏不知的,因为如果订单为有效订单,那么客户可能不知道在提交订单时还存在这一操作。实际说来,验证订单其实是提交订单的一个执行步骤”
2)角色
一个业务服务必须有一个角色作为发起者,他会触发业务请求,通常包括用户,策略、伴生系统
3)执行序列
业务服务的执行序列意味着执行的所有步揍都是连续且不可中断的,如此才能完成一次完整的业务交互
2、业务服务的呈现
业务流程和通过业务流程图和服务蓝图以可视化协作的形式进行呈现,而业务场景和业务服务则借用了UML 用例图形式的业务服务图
1)业务服务图
用例图的组成要素和业务场景的
5W
模型非常相似,二者形成了如下的
组成部分 | 说明 |
---|---|
参与者 | Who :不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。因此参与者可以是人,可以是事物,也可以是时间或其他系统等等 |
用例 | What :是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。 |
关系 | Why :参与者与用例之间的关系主要包括关联、归纳(泛化)、包含、拓展 |
边界 | Where :代表了 5w 中的 where |
用例图中的一个椭圆形表示一个系统用例,这里用来表示业务服务,
五、子领域
当目前系统的问题空间通过业务流程,业务场景,业务服务呈现在团队面前,问题空间才变得清晰起来。然后我们将全局分析的粒度控制在业务服务层次,如果是一个庞大的问题空间,这些业务单元 仍然过散,过细。不利于形成利益相关者,领域专家,和开发团队对问题空间的共同理解
因此,我们需要一个粒度合理的业务单元,一方面降级问题空间规模庞大带来的业务复杂度,另一方面帮助领域专家和开发团队更好把握问题空间而不至于迷失在细节中,这个业务单元就是子领域
1、子领域元模型
⬤ 子领域属于问题空间的范畴
⬤ 子领域用于分辨问题空间的核心问题和次要问题
子领域 | 说哦名 |
---|---|
核心子领域 | 能够体现系统愿景,具有产品差异化和核心竞争力的业务服务; |
通用子领域 | 包含的内容缺乏领域个性,具有较强的通用性,例如权限管理和邮件管理; |
支撑子领域 | 包含的内容多为“定制开发”,其为核心子领域的功能提供了支撑。 |
2、子领域的划分
划分问题空间的子领域仍然是 分而治之 思想的体现,是控制问题空间复杂度的一种手段。关键在于去定义核心子领域。 根据目标系统的功能分类策略可以进行子领域的分解
功能分类 | 说明 |
---|---|
业务职能: | 当目标系统运用于企业的生产和管理时,与目标系统业务有关的职能部门往往会影响目标系统的子领域划分,并形成一种简单的映射关系。这是康威定律的一种运用。 |
**业务产品: ** | 当目标系统为客户提供诸多具有业务价值的产品时,可以按照产品的内容与方向进行子领域划分。 |
业务环节 | 对贯穿目标系统的核心业务流程进行阶段划分,然后按照划分出来的每个环节确定子领域。(这也是我们最常用的策略) |
业务概念: | 捕捉目标系统中一目了然的业务概念,将其作为子领域 |
1)业务职能:
如果按照业务职能划分子领域,只需要了解企业的组织结构,就可以轻而易举地获得对应的子领域。
例如为一所学校开发一套管理系统,按照学校的业务职能划分,就可以获得教务、学生管理、科研、财务、人事等子领域,
这些子领域实际上恰好对应学校的职能部门,如教务处、学生处、科研处、财务处、人事处等。
在识别子领域时,需要就目标系统的范围确定组织结构的范围,例如管理系统的范围没有要求支持图书馆的管理,我们就不需要考虑图书馆这一机构,也不会识别出图书馆子领域。
2)业务产品:
如果按照业务产品划分子领域,就可以确定企业的产品线或业务线,根据描绘出的业务结构得到各个与之对应的子领域。
例如,为银行开发网银系统,就可以根据储蓄业务、信用卡业务、理财业务、外汇业务、保险业务等业务产品确定对应的子领域。同理,在确定这些子领域时,也需要界定它是否在目标系统的范围内。
3)业务环节
若根据业务环节划分子领域,确定核心业务流就成为重中之重。对一个全景流程而言,一定存在多个明显的时间节点,将流程划分为具有不同目标的业务环节。
例如,一个典型的电商平台买家购买商品的业务流程就是该目标系统的其中一个核心业务流,该业务流明显可以划分为购买,仓储,配送,售后等业务环节。
4)业务概念:
如果要通过捕捉业务概念的方法识别子领域,就需要依靠对问题空间的深刻理解和一种分析中的直觉。寻找的业务概念往往属于人、事、物中的一种,由此形成的子领域其实就是对这些概念的管理。
例如,当我们想到一款音乐在线平台时,一下子浮现在我们脑海中的业务概念会有些?音乐、歌手、直播、电台 ·….这些业务概念是否一目了然呢?当然!根据这些业务概念就能到与之对应的管理这些业务概念的子领域,如歌手子领域的主要功能,就是对歌手的管理。
划分了子领域后,还需要结合价值需求中的系统愿景判断哪些子领域是核心子领域,哪些子领是通用或支撑子领域。
当然,上述列出的功能分类策略未必能帮助我们穷尽整个问题空间的子领域,但它们确实为子领域的识别提供了不错的参考。识别子领域时,确定核心子领域是关键,也是识别过程的起点。
⬤ 在获得了核心子领域之后,再来通盘考虑这些核心子领域都需要哪些通用功能,又或者针对一个个核心子领域,去寻找与它相关却并非核心关注点的支撑功能,即可获得通用子领域和支撑子领域。
不可否认,划分子领域的过程存在很多经验因素,一个对该行业领域知识了如指掌的领域专家,可以在确定了目标系统的愿景与范围之后,快速地给出一份子领域列表。因此,领域专家的参与就显得至关重要,开发团队要和领域专家协作,把这份可能存在于领域专家脑海中的子领域列表显现出来,然后就子领域的划分、名称和分类进行讨论,一旦确定了子领域,再将之前识别出来的业务服务分配到各个子领域,形成对问题空间的共同理解。
3、子领域映射图
获得的子领域最好以子领域映射图的形式进行可视化,用整个桶圆形代表目标系统的问题空间,从楠圆中划分出来的每一个区域代表一个子领域。每个子领域标记了它究竟是核心子领域、通用子领域还是支撑子领域。文学平台的子
用户管理(通用子领域领域映射图如图6-10所示。分析问题空间时,必须从业务角度进行沟通和交流,对子领域的划分也不例外。如果将技术方案带入这个过程中,全局分析就会变味,获得的子领域就会掺杂解决方案的内容,或者干脆受到解决方案的影响,形成一些偏技术的子领域”
领域驱动设计统一过程旗帜鲜明地将全局分析阶段划入问题空间的范畴,正是基于这一目的。为了减少技术方案对子领域的影响,可以考虑在划分子领域时,将那些具有技术背景的团队角色 ( 如技术负责人、开发人员 ) 排除在外,只保留领域专家、业务分析师、业务架构师、项目经理和测试人员,除非技术角色能够分清问题空间与解空间的界限。