3.2 业务架构元模型 应用

3.2.1 现代业务架构典型问题

在帮助企业构建业务架构的过程中，我们发现大部分企业正面临共同的问题：如何抽离多业务线共享的能力，集中管控和演进，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？

问题的背景和起因在于，当大型企业的业务发展到达一定规模，多条业务线并存、或多个业务单元并行发展，IT 建设会随着业务边界、组织边界，不可避免的进一步分化，也加剧了 IT 部门进行统一管控的困难。

一方面，在很多场景中，这样的分化带来了双重投资甚至多重投资的浪费，另一方面也在加剧本就存在的用户或者客户体验的割裂、数据孤岛、IT 翻新周期长等固有问题。

同时，当业务线不断尝试新的业务模式，或对于已有模式进行更快的试验、调整与扩展。对于 IT 支撑的响应力也提出了更高的要求。固有的系统搭建或者产品部署模式，越来越不足以提供及时的响应，且在“快速试错”、“小步快跑”的创新场景应对下，成本高昂。

为了解决上述问题，我们对问题进行了进一步拆解：

• Q1：什么是可共享复用的能力？
• Q2：如何识别和构建能力？
• Q3：如何使用能力，实现新业务快速上线？

在对问题进行上述拆解后，我们将基于业务架构元模型逐一解决。

3.2.2 什么是可共享复用的能力？

在现代企业架构中，面向能力的规划超越面向功能与服务的规划成为企业级业务架构规划的关注要点，如何基于能力的识别与规划，最大化的沉淀企业级可复用的能力，并通过扩展、编排和组合等形式应用到更多的场景，是平台型企业架构需要解决的关键问题。

企业为了应对业务的快速迭代、多场景和不确定性，需要在平台上构建可复用的“能力”以及为能力提供必要的扩展与可变机制，以此为不同前台提供灵活多变的业务服务，满足不同前台差异化个性化的的需求。

而“能力”根据粒度的不同，可再度细分为“基础能力”、“能力组件”和“解决方案”三个层级。不同业务的差异性，则可通过能力的“扩展点”设计和不同“业务身份”在扩展点上的“扩展实现”进行区分。

总体实现机制如下：

( 图 3.2-2 企业能力共享复用的实现机制 )

• 业务身份： “业务身份”的概念最早由阿里巴巴提出，业务平台在对各业务同时提供服务时，需要能区分每一次业务服务请求的业务身份要素，以便提供差异化个性化的服务；因此需要对企业各业务的身份和特征进行建模和区分，其产出即为“业务身份”。 业务身份是业务在平台中的代名词，是在业务运营中唯一区分某个具体业务的 ID。平台基于业务身份匹配该特定业务的流程和业务规则，并基于业务身份实现服务路由、需求溯源、业务监控和业务隔离。
• 基础能力： 是对领域对象的原子操作，完成一个领域对象上单一且完整的职责。比如：创建售后单、修改商品库存量等，是能力组合和复用的最小单元。
• 能力组件： 能力组件是对基础能力的进一步封装，目的是方便业务的使用。按封装粒度不同分为两类：第一类能力组件是根据业务服务的需要编排封装的一组关联的基础能力，从而提供完整的服务。比如：订单创建能力组件。第二类能力组件是平台针对一系列紧密关联的业务活动，设计的能力模板，可基于该模板快速定制某个具体业务的特定流程和能力，从而达到复用全部关联能力的目的。比如：“组合支付”、“快速建站”等能力组件。能力组件加快了业务接入平台的速度，让业务侧专注业务本身，不再需要耗费精力在理解平台大量的基础能力上。
• 扩展点与扩展实现： “扩展点”是对基础能力的可变性设计，在技术侧体现为基础能力实现中的某一个步骤的接口定义，而接口的一个实现即为一个“扩展实现”。比如：订单渲染基础能力中有一个步骤是订单总价试算，而正常时期的总价试算规则与秒杀时期的总价试算规则是不同的，因此需要对订单渲染基础能力设计“订单总价试算规则”的扩展点，并分别定义在正常时期和秒杀时期的扩展实现。
• 解决方案： 是平台针对一类共性业务的端到端过程设计的能力模板；可基于该模板快速定制某个具体业务的特定能力和流程，从而达到业务模式级别复用的目的。比如：虚拟物品交易解决方案。

3.2.3 如何识别和构建能力？

识别构建能力的过程分为“业务梳理”和“模式设计”两个阶段。

在业务梳理阶段：对企业业务、流程、组织、业务服务和业务规则进行细致完整地梳理，作为后续模式设计的基础和输入。

而在模式设计阶段：则会通过流程建模、领域建模、业务身份建模和能力建模 4 个步骤完成企业能力的识别构建。

具体过程如下：

( 图 3.2-3 识别和构建能力的过程 )

模式设计阶段中：

• 流程建模：负责识别共性业务，并抽取通用流程，设计可变点，作为可复用性分析的基础。
• 领域建模：负责基于流程建模结果，识别领域事件和领域对象，并划分子域的边界；领域对象构成了提供可复用能力的基本单元，对领域对象的操作即是基础能力。
• 业务身份建模：负责定义业务身份识别的要素和业务身份解析规则，用于给可复用的能力区分不同的业务身份要素。
• 能力建模：负责最终完成平台三类可复用能力的设计，即“基础能力”设计、“能力组件”设计和“解决方案”设计。

下面将详细说明各步骤的实施方法：

3.2.3.1 流程建模

为了提取可复用的能力，首先需要识别共性业务，然后将同一类共性的业务抽象提炼出通用流程，并基于通用流程进行可变性分析。

具体方法是按业务架构中流程部分的元模型（阶段、活动、任务、步骤、业务规则），结合自上而下以及自下而上的方式逐层提炼收敛通用模型和可变点。

总体实现机制如下：

( 图 3.2-4 流程建模的总体实现机制 )

提炼通用流程后的可变性分析，旨在找出“什么在变”、“为什么变”和“怎么变”，因此可变性模型主要由：“可变点”、“可变点实现”以及“可变点、可变点实现之间的关系”三部分组成。

( 图 3.2-5 可变性模型的组成部分 )

综上所述，流程建模的主要步骤如下：

• 分析业务组合，提取共性业务。
• 分析所有共性业务的各流程 步骤及其输出对象，抽象提炼通用步骤和业务实体；识别各业务的差异部分，提炼设计可变点，确定可变点实现和关系。
• 分析所有共性业务的各流程 任务，抽象提炼通用任务；识别各业务在任务上的差异部分。
• 分析所有共性业务的各流程 活动，抽象提炼通用活动；识别各业务在活动上的差异部分。
• 分析所有共性业务的各流程 阶段，抽象提炼通用阶段；识别各业务在阶段上的差异部分。

3.2.3.2 领域建模

领域是指组织的业务范围以及在其中所进行的活动，也就是平台能力需要支撑的业务范围。因此，为了构建出平台能力，需要对业务 领域进行深入的理解和设计。

在业务架构部分，将进行领域战略层级的建模，主要包括：“子域”、“领域对象”、“领域事件”部分的设计。

( 图 3.2-6 领域战略层级建模的组成部分 )

领域战略层级建模的过程如下：

( 图 3.2-7 领域战略层级建模的过程 )

3.2.3.2.1 领域事件识别

领域事件（Domain Event）：是领域专家关心的，在业务上真实发生的事件，这些事件对系统会产生重要的影响，如果没有这些事件的发生，整个业务逻辑和系统实现就不能成立。我们可以通过领域事件对过去发生的事情进行溯源，因为过去所发生的对业务有意义的信息都会通过某种形式保存下来。比如：“用户地址已更新”、“订单已发货” 等领域事件。

领域事件对系统常见的影响有：

• 对内
  • 产生了某种数据
  • 触发了某种流程或事情
  • 状态发生了某种变化
• 对外
  • 发送了某些消息

目前比较常用的领域事件识别方法是“事件风暴（Event Storming）”，主要步骤如下：

• 邀请业务专家（或领域专家）和技术专家共同参与事件风暴工作坊，其它参与角色按需补充。
• 明确和选择需要分析的业务 场景。
• 确定起始事件和结束事件，事件以“XXX 已YYY”的形式进行命名。
• 根据场景和业务复述的复杂度，决定以时间线的哪个方向开始梳理事件（正向或逆向）。
• 以先发散再收敛的方式，按照时间线的先后顺序和并行关系，补充和完善领域事件。
• 使用“规则”抽象分支条件或复杂的规则细节，通过抽象降低分支复杂度，规则以“XXX 规则”的名词形式进行命名。
• 完成一遍事件梳理之后，通过问问题的方式，逆向检查（Reverse Check）事件流的逻辑合理性，例如：
  • 该事件真的需要在系统实现的时候考虑吗？
  • 该事件如果存在，那它的前提条件是什么？
  • 该事件如果要产生，那它的前一个事件必须是？
• 重复以上步骤，迭代式的完成全部领域事件的识别。

领域事件识别的示例如下：

( 图 3.2-8 领域事件识别的示例 )

3.2.3.2.2 领域对象识别

领域对象（Domain Object）：是对业务的高度抽象，作为业务和系统实现的核心联系，领域对象封装和承载了业务逻辑，是系统设计的基础。

领域建模中重要的部分之一就是对“领域对象”及领域对象之间关系的识别和设计。而领域对象识别将基于前面领域事件识别的结果开展。

领域对象，通常包含（但不限于）：

• 领域事件中出现了的名词；
• 如果没有信息系统，在现实中会看得见摸得着的事物（例如订单）；
• 虽然在当前业务中看不见摸不着，但是可以在未来抽象出来的业务概念。

在领域驱动设计（Domain-Driven Design）（参考文献 7）中一般存在三类领域对象：

1. 聚合根：是领域对象的根节点，具有全局标识，对象其它的实体只能通过聚合根来导航；如订单可以分为订单头和订单行，订单头是聚合根，它包含了订单基本信息；订单行是实体，它包含订单的明细信息，聚合根所代表的聚合实现了对于业务一致性的保障，是业务一致性的边界。
2. 实体：是领域对象的主干，具有唯一标识和生命周期，可以通过标识判断相等性，并且是可变的，如常见的用户实体、订单实体；
3. 值对象：实体的附加业务概念，用来描述实体所包含的业务信息，无唯一标识，可枚举且不可变，如收货地址、合同种类等等。

业务架构只负责初步和整体识别领域对象，而对领域对象的分类（聚合根、实体、值对象）和战术层级的详细设计将在应用架构设计部分完成。

领域对象识别的主要步骤如下：

• 对每一个领域事件，快速识别或抽象出与该领域事件最相关（或隐含的）的业务概念，并将其以名词形式予以贴出。
• 检查领域名词和领域事件在概念和粒度（例如数量，单数还是集合）上的一致性，通过重命名的方式统一语言，消除二义性。
• 如果在讨论过程中，有任何因为问题澄清和知识增长带来的对于之前各种产出物的共识性调整，请不要犹豫，立刻予以调整和优化。
• 重复以上步骤，迭代式的完成全部领域对象的识别。

领域对象识别的示例如下：

( 图 3.2-9 领域对象识别的示例 )

3.2.3.2.3 子域划分

子域（Subdomain）：是对问题域的澄清和划分，同时也是对于资源投入优先级的重要参考。比如：“订单子域”、“物流子域”等，子域的划分仍属于业务架构关注范畴。

子域的类型分为：

( 图 3.2-10 子域的类型 )

1. 核心域（Core Domain）：是当前产品的核心差异化竞争力，是整个业务的盈利来源和基石，如果核心域不存在那么整个业务就不能运作。对于核心域，需要投入最优势的资源（包括能力高的人），和做严谨良好的设计。
2. 支撑域（Supporting Subdomain）：解决的是支撑核心域运作的问题，其重要程度不如核心域，但具备强烈的个性化需求，难以在业内找到现成的解决方案，需要专门的团队定制开发。
3. 通用域（Generic Subdomain）：该类问题在业内非常常见，所以很可能有现成的解决方案，通过购买或简单修改的方式就可以使用。

子域划分的示例如下

( 图 3.2-11 子域划分的示例 )

子域划分的主要步骤如下：

• 根据“每一个问题子域负责解决一个有独立业务价值的业务问题”的视角出发，可以通过疑问句的方式来澄清和分析子域需要解决的业务问题，例如“如何进行库存管理？（英文描述类似 How to…？）”。
• 利用虚线，将解决同一个业务问题的限界上下文以切割图像的方式划在一起，并以“XXX 子域”的形式对每个子域进行命名。
• 根据三种类型的子域定义，共同结合业务实际（或者参考设计思维中的电梯演讲），确定每个子域的子域类型。

3.2.3.3 业务身份建模

业务身份由“业务身份 ID”、“业务身份名称”、“业务身份要素定义”、“业务身份识别解析规则”四个部分组成。

( 图 3.2-12 业务身份的组成部分 )

其中，业务身份要素定义是最基础、也是最难的部分。企业应根据自身业务特征对身份要素进行识别定义，常见的身份要素维度包括但不限于：客户、产品和渠道等。

业务身份要素除了对要素维度进行抽取识别，还需要定义每个要素维度所包含的领域对象（包括领域对象的属性）；这些领域对象及其属性用来定义业务身份识别解析规则。实现机制如下：

( 图 3.2-13 业务身份解析机制 )

业务身份建模的主要步骤如下：

• 分析业务组合，提取业务身份要素维度。
• 确定各业务身份要素维度对应的领域对象（包括领域对象的属性）。
• 确定领域对象各属性的取值条件规则，定义业务身份识别解析规则。
• 指定业务身份名称。
• 指定业务身份 ID。

3.2.3.4 能力建模

能力建模分为基础能力和扩展点设计、能力组件设计和解决方案设计三个部分，过程顺序如下：

( 图 3.2-14 能力建模的过程顺序 )

3.2.3.4.1 基础能力与扩展点设计

基础能力：是对领域对象的原子操作，完成一个领域上单一且完整的职责。比如：创建售后单、修改商品库存量等。

扩展点与扩展实现：“扩展点”是对基础能力的可变性设计，在技术侧体现为基础能力实现中的某一个步骤的接口定义，而接口的一个实现为一个“扩展实现”。比如：订单渲染基础能力中有一个步骤是订单总价试算，而正常时期的总价试算规则与秒杀时期的总价试算规则是不同的，因此需要对订单渲染基础能力设计“订单总价试算规则”的扩展点，并分别定义在正常时期和秒杀时期的扩展实现。

不同的业务通过使用同一个基础能力来达成共享复用的目的，而不同业务在业务规则上的差异性，则通过定义该基础能力在扩展点上的不同扩展实现来区分。

需要注意的是，通常这套机制需要技术上的开发框架支持。

基础能力与扩展点设计的主要步骤如下：

• 对流程建模步骤中输出的各任务下的所有步骤，确定其对应的领域对象（注意，该领域对象应来自于前面的领域建模步骤）。
• 根据步骤对领域对象的操作，设计对应的基础能力；基础能力的设计应遵循如下原则：
  • 完成对一个领域对象单一且完整的操作职责
  • 基础能力操作的领域对象最大不能超出单个聚合，最小不能破坏业务的一致性要求
  • 基础能力的输入与输出建议对象化，以规范使用
  • 根据流程建模步骤中识别出的与该基础能力有关的可变点，以及各业务身份在该可变点上不同的业务规则，提炼设计出基础能力的扩展点
• 确定扩展点的默认实现（即默认情况下基础能力执行的业务规则）

3.2.3.4.2 能力组件设计

能力组件：是对基础能力的进一步封装，目的是方便业务的使用。能力组件加快了业务接入平台的速度，让业务侧专注业务本身，不再需要耗费精力在理解平台大量的基础能力上。

能力组件按封装粒度不同分为两类：

第一类能力组件是根据业务服务的需要编排封装的一组关联的基础能力，从而提供完整的业务服务。比如：订单创建能力组件。

第二类能力组件是平台针对一系列紧密关联的业务 活动，设计的能力模板，可基于该模板快速定制某个具体业务的特定流程和能力，从而达到复用全部关联能力的目的。比如：“购物车”、“结算”、“快速建站”等能力组件。

实现机制及示例如下：

( 图 3.2-15 能力组件的实现机制及示例 )

基础能力与能力组件的设计都基于流程建模和领域建模的结果，各设计产出要素的对应关系如下：

（图3.2-16 基础能力、能力组件设计与流程和领域建模的关系）

能力组件设计的主要步骤如下：

• 对流程建模中输出的每个任务，设计其所需的业务服务，可采用服务蓝图的方法进行业务服务设计。
• 对每个业务服务，封装编排满足其需求的一组基础能力成为第一类能力组件。
• 对流程建模中输出的阶段和业务活动进行逐项分析，从价值交付和阶段性价值交付的角度，识别对应的一系列紧密关联的业务活动；将这些业务活动包含涉及的所有能力组件和基础能力封装定义为第二类能力组件。

3.2.3.4.3 解决方案设计

解决方案：是平台针对一类共性业务的端到端过程设计的能力模板；可基于该模板快速定制某个具体业务的特定能力，从而达到业务模式复用的目的。比如：虚拟物品交易解决方案。

从以上定义可以看出，解决方案的核心是对共性业务进行识别提取和对业务全部能力进行模板化封装。

（图3.2-17 解决方案设计的过程）

解决方案设计的主要步骤如下：

• 识别和提取共性业务。
• 对共性业务进行流程建模和领域建模，具体方法参见前面所述。
• 进行基础能力和扩展点设计。
• 进行能力组件设计。
• 基于通用流程，将共性业务中包含的所有基础能力、扩展点和能力组件封装定义为解决方案。

3.2.4 如何复用能力，实现新业务快速上线

3.2.4.1 多层级复用

在平台化架构中，能力的复用可分为三个层级：

其中业务能力复用和业务模式复用层级都对可复用能力的识别和设计提出了要求。因此，基于前面论述的可复用能力构建方法，我们就能实现这两层的复用效果。

多层级复用为什么能实现呢？

首先在于底层领域模型的设计，有了建模后的领域对象提供共享的基础能力，再加上扩展机制，就能实现基础能力在不同业务上的复用；

而经过通用流程的建模，这些基础能力又能进一步组装成更大粒度的可复用能力组件，从而实现局部业务流程的复用；

如果业务流程的复用能够延伸到业务的全流程，即对于同一类共性业务其全流程都能基于一个解决方案模板定制，而这个解决方案模板是其下所有能力组件和基础能力的封装，那么新的业务只需定制该解决方案模板即可实现业务模式复用，快速上线新业务。

其关系如下：

（图 3.2-18 多层级复用的关系）

3.2.4.2 复用基础能力和能力组件

在识别和构建了平台的基础能力和能力组件之后，不同业务就能针对特定的业务需求复用它们并快速定制。方法是对基础能力下的扩展点进行扩展实现的配置和开发，示例如下：

（图 3.2-19 复用基础能力和能力组件的示例）

复用基础能力和能力组件的主要步骤如下：

• 配置新业务对应的业务身份在各基础能力 扩展点上的扩展实现，如果无需定制可直接采用默认扩展实现。
• 开发基础能力的扩展实现。
• 根据业务流程，编排基础能力和能力组件，实现业务需求。
• 对于现有能力不能满足业务需求的情况，需要平台侧新增开发任务，修改或者新增基础能力和能力组件；然后应用侧按上述过程完成定制使用。

3.2.4.3 复用解决方案

对于新业务，如果已构建了其所属共性业务的解决方案，则可通过复用该解决方案进行业务的快速定制。方法是：基于解决方案的通用流程定制新业务流程，并对基础能力下的扩展点进行扩展实现的配置和开发。

（图 3.2-20 复用解决方案快速定制新业务）

复用解决方案的主要步骤如下：

• 基于选定的解决方案，配置新业务的业务全流程。
• 配置新业务对应的业务身份在各基础能力 扩展点上的扩展实现，如果无需定制可直接采用默认扩展实现。
• 开发基础能力的扩展实现。
• 根据业务全流程，编排基础能力和能力组件，实现业务需求。
• 对于现有能力不能满足业务需求的情况，需要平台侧新增开发任务，修改或者新增基础能力、能力组件和解决方案；然后应用侧按上述过程完成定制使用。