业务中台构建策略划分子域上下文事件风暴需求结构化.docx

业务中台构建策略划分子域上下文事件风暴需求结构化.docx

《业务中台构建策略划分子域上下文事件风暴需求结构化.docx》由会员分享，可在线阅读，更多相关《业务中台构建策略划分子域上下文事件风暴需求结构化.docx（6页珍藏版）》请在冰豆网上搜索。

业务中台构建策略划分子域上下文事件风暴需求结构化

业务中台构建策略：

划分子域、上下文、事件风暴、需求结构化

业务中台构建策略

本文会细介绍构建业务中台的具体策略：

领域驱动、需求结构化和能力可配置。

首先，我们通过领域驱动，从整体上划分业务中台的领域，进而划分出业务中台的具体能力中心；其次，对具体的领域进行细化。

在这里我们会使用需求结构化和能力可配置两种策略，最终形成易用、灵活的业务能力中心。

领域驱动设计

业务中台的构建，首先需要进行整体规划。

对企业而言，中台所涉及的内外部系统交错复杂，而领域驱动设计（Domain-DrivenDesign，DDD）是厘清这些错综复杂系统的一种实践策略。

借鉴领域驱动设计，我们可以梳理业务应用系统所涉及的各角色的旅程地图，包括运营者、消费者、客服、导购等，然后根据用户旅程地图所涉及的业务对象或实体，剥离差异性，抽取共性，最终形成共享的服务能力。

领域驱动设计最早是由EricEvans提出的，目的是对软件所涉及的领域进行建模，以应对系统规模过大时引起的软件复杂性问题。

以领域驱动构建业务中台的过程可以分为战略和战术两大阶段。

1.战略阶段

业务中台建设的战略阶段的核心目的是划分问题域，确定核心领域，整理出限界上下文。

领域按照类型可划分为核心领域、支撑子域和通用子域。

实现业务愿景和价值的主要系统功能即是核心域，用来支撑核心域的子域称为支撑子域，而相对通用的则称为通用子域。

限界上下文为领域提供上下文语境，确保领域内的术语在其特定的边界范围内具有一个没有二义性的含义。

领域驱动的业务中台构建过程中，首先从业务维度出发，开发者与领域专家使用通用语言进行信息的沟通及确定，梳理出业务关键的核心域及支撑核心领域的子域。

在过程中，也会浮现一些通用系统需求及出于技术维度方面考虑的场景，这就形成了通用子域。

在领域划分的基础上，我们将中台所涉及的业务领域划分为通用能力域及商业能力域（见图3-5）。

对于一个系统而言，用户管理、登录认证、消息发送、数据字典等通用功能，可以形成通用能力域。

而针对客户互动相关的场景（如消费者浏览商品并下单购买，消费者享受会员权益，平台通过各种促销活动促进交易等），所涉及的商品中心、交易中心、库存中心、会员中心、营销中心等促进商业行为的领域，可以形成业务中台的商业能力域。

通用能力域主要关注基础功能性能力，为商业能力域提供基础支持；而商业能力域主要关注各类商业领域能力，以进一步支撑前台业务的多样化场景。

图3-5　业务中台领域的划分方式

与传统DDD不太一样的是，我们不太强调支撑子域。

这是因为中台是企业应用的共享服务平台，它将支撑各色各样的业务应用。

从不同的业务应用角度区分核心域和支撑子域是有意义的。

但从业务中台的角度，就没太大必要分出哪个是核心域，哪个是支撑子域。

当然，我们在业务中台的建设过程中，还是会区分核心域和支撑子域，因为业务中台建设是由业务应用驱动的。

2.战术阶段

在将系统划分为多个能力中心后，中台建设就进入战术阶段。

在战术阶段，针对已确定的能力中心，中台要进行具体领域设计。

在此阶段，我们会更关注领域内部的要素。

我们一般使用领域模型来表达领域知识。

常见的领域模型包括实体、值对象、领域服务、领域事件和聚合等。

∙以交易上下文为例（见图3-6），在该限界上下文中，关键核心为交易（Transaction）。

∙交易体现的不只是一个订单，还体现了一个交易动作。

∙一个交易会产生很多种单据，如交易订单（TradeOrder）、支付订单（PayOrder）、发货订单（DeliveryOrder）等。

∙一个交易订单会由一条或多条订单商品信息（OrderItem）组成。

这些单据包含对应的单据ID、状态及其他实体属性，它们就是限界上下文的实体。

∙交易上下文中，所有实体、值对象都围绕着交易，而外部需要访问交易上下文，必须从交易开始，所以交易可视作一个交易上下文的聚合根。

当一个消费者下单后，首先会创建交易实体，在创建该聚合根实体的过程中，还需要创建对应的多种单据。

∙为了完整构建、初始化交易实体，我们可通过工厂（TransactionFactory）来封装具体的创建逻辑。

图3-6　交易上下文的示例领域模型

每个实体均会涉及状态的改变，而这种状态改变的动作可以触发一个领域事件。

领域事件一般是“名词+动词过去式”。

消费者下单后将产生一个订单已创建（OrderCreated）的领域事件。

对于交易订单实体而言，创建订单属于实体的能力。

而下单过程中，需要扣减库存（DeductStock），该动作在交易上下文中涉及了其他上下文的领域对象，所以可以通过领域服务进行协调，进而保证不同上下文的一致性。

综上，在领域驱动设计的过程中，我们通过战略、战术两个阶段，从宏观上整体划分领域边界，将业务中台划分为通用能力域及商业能力域，进而针对每个能力中心，不断细化领域对象，形成丰富的领域对象模型，将领域能力构建成具体业务中心的能力。

3.基于事件风暴的DDD

不过，对于如何可操作地实施DDD，业界有很多不同的探索，而其中事件风暴（EventStorming）是一种既经济又高效而且充满乐趣的方法，也被证明是一种可以快速探索复杂业务领域的方法。

事件风暴是一种战术阶段的设计方法，它自下而上地从微观的领域事件推演出战略层宏观的领域模型。

它被业界戏称为“糊墙”，因为它会在一个房间的四面墙上糊满便利贴。

它几乎没有学习曲线，唯一稍微有点高的要求是要有一间足够大的房间，并且有足够多的不同颜色的便利贴。

它的核心是协同共创，要求领域专家、业务架构师与技术人员以协同的方式迭代地探索构建出领域模型。

事件风暴的理论基础来自领域事件。

如果一个系统能够支持一项业务，那么当该业务开展时，角色在业务上的操作就会导致系统的响应，从而留下一些足迹。

这些足迹往往以数据的形式存在于某个地方。

留下这种足迹的系统的响应就是领域事件。

通过对领域事件足迹的追踪可以推测当时的业务操作。

如果把领域事件按照时间排序，就能在时间线上还原一系列业务行为，从而推导出系统所需的能力，并通过技术性的手段转化为系统的空间结构。

而系统的空间结构就是系统的领域模型。

图3-7所示为一个对商城中同城配送需求进行事件风暴后得到的领域事件流。

首先，事件风暴的展开是基于业务场景的。

在这个需求中，领域专家识别出了店铺创建、同城配送设置、商品选购、订单确认、接单、配送几个业务场景。

然后，展开每个业务场景，从左到右识别出该场景下的领域事件，以及触发该事件的命令和角色。

这些事件流是后续建模工作的战术层输入，基于它们就可以逐步推演出领域模型。

图3-7　领域事件流

经过事件风暴，既可发现与通用模型的重叠之处，也可找出差异点。

如此，我们不仅最大程度复用了中台现有能力，也通过增加差异点持续扩展了中台的能力。

对于如何基于事件风暴构建业务中台领域模型，可参考图3-8所示流程。

1）业务架构师与领域专家主导，带领团队按照业务场景识别领域事件、命令与角色，并按照时间排序。

2）业务架构师与领域专家带领团队，基于战术层的业务场景与事件流提炼子域。

对于中台来说，可以认为子域是能力中心。

但这个时候，能力中心还处于问题域空间，没有任何解决方案。

3）技术人员带领团队基于事件流提取业务元素，识别实体、值对象及聚合。

4）技术人员再次带领团队，跨越到战略层，识别出限界上下文及其映射与集成的关系，并验证是否有足够的能力解决能力中心的问题。

这个时候，能力中心的问题由限界上下文解决，业务中台架构终于从问题过渡到了解决方案。

图3-8　事件风暴基本流程

　需求结构化

业务中台的核心价值在于能力的共享。

中台能力使用方在接触业务中台时面临的首要问题是：

如何了解业务中台有哪些能力？

这些能力与实际业务场景的匹配程度如何？

因此，业务中台的构建首先需要考虑业务能力的呈现方式。

我们以业务场景、业务能力、业务配置的层次来结构化地表达业务需求。

需求结构化体现的是一种结构化思维，即在面对需求问题时，采用一种层次结构将需求进行拆解。

在未中台能力结构化展现时，想要了解中台所提供的能力，一般是通过API列表，而且只局限于开发人员，因为业务人员不易理解API列表。

但是，需求结构化不仅让我们更易于了解业务中台的共享能力，还扩大了受众人群。

需求结构化，一般可以从两个维度来体现。

能力地图：

从领域、场景、能力的结构化层次，可视化地体现需求场景和流程中的每个节点。

如此一来，中台能力使用方可基于原始需求快速匹配可用的业务领域、场景及能力。

而对于不存在的业务场景，能力使用方则形成当前需求的场景能力开发项。

配置视图：

在同一业务领域，不同的业务场景会导致不同的业务规则。

通过配置视图，中台能力使用方可以查看业务中台已有的业务规则，与当前的业务场景规则进行匹配。

若规则已存在但与当前所需的规则策略不匹配，则形成规则的扩展实现开发项；如规则为当前业务场景特有，则可以形成定制实现开发项。

综上，通过能力地图、配置视图，我们能够将业务场景、业务规则以系统结构层次的方式串联起来。

按照需求结构化方式，针对具体需求，我们首先会整理出需使用的场景、能力、配置，并在现有的系统上梳理出需要新增的开发场景、能力、规则，形成最终需求需要开发和配置的条目。

业务中台不是一蹴而就的。

需求结构化的方式一方面可以让中台使用方更易于应用共享能力，验证业务能力；另一方面也能不断沉淀更多的业务能力、业务规则配置及扩展项。

这也是业务中台不断自我演进的方式。

3.3.3　能力可配置

因为业务能力之间存在差异性，所以业务规则也不全相同。

比如，同样都是下单能力，对普通商品而言，下单动作只需校验基础商品、库存的有效性；但对于热门抢购商品而言，在基础校验完成后，下单前系统还可能增加商品限购的校验。

根据不同的使用场景，商品限购校验也会存在多种限购规则和策略，如会员等级限购、会员预约限购等。

由此可见，不同场景下同一个下单能力所涉及的业务规则并不完全相同。

因此，业务中台作为能力共享的平台，如何针对不同的业务场景、业务对象（如商品、店铺）进行不同业务规则的配置以及配置的隔离，就是一个必须解决的问题。

中台在实现通用业务规则的基础上，将其针对不同业务场景的可变部分提取出来，作为业务的可配置项，并对这些可配置项进行统一管理，就形成了中台能力可配置的特性。

业务配置项一般分为两种类型。

业务参数：

业务参数是针对既定范围内可变业务规则的业务控制点。

以系统登录能力为例，有些业务场景针对同一账号，在同一时间只允许一处登录，而有些业务场景则允许多处登录，并支持可配置具体的多端登录数量。

为此，在系统登录能力下，可以挂载一个“是否允许多端同时登录”配置项。

我们将这种配置项称为业务参数。

通过业务参数，我们可以统一管理系统既定范围内可选的业务规则。

如此一来，业务人员只需根据不同的场景设置具体业务参数的值即可。

业务扩展点：

业务扩展点是在业务参数的基础上，满足不确定候选值业务规则的另一种业务控制点。

以全渠道订单同步能力为例，比如某企业既有自营的商城订单，也有第三方平台渠道的商城订单，如天猫、京东、唯品会等，不同渠道有不同的订单同步规则及数据格式。

为此，我们可以在订单能力下挂载一个“订单同步渠道”扩展点，将第三方平台渠道的订单进行同步。

在业务发展的过程中，企业可能会继续接入拼多多、抖音等渠道，但它们都有不同的业务实现。

因此，我们将这种类型的配置项称为业务扩展点。

业务扩展点定义了中台统一业务逻辑与业务个性化实现的一个接口契约。

只要遵照该契约，根据业务需要，我们就可以随时扩展不同的业务规则逻辑。

这也是业务中台所需的另一个很重要的特性—动态化扩展。

业务中台的建设过程是一个不断整理、实现配置项的过程。

通过不断丰富业务中台的可配置化能力，不断打磨业务能力，让业务中台成为支撑前端业务快速创新的利器。