3.3 业务中台构建策略
上一节介绍了业务中台的核心架构与体系。那么围绕核心架构和体系，业务中台应该按照怎样的方式进行构建？
接下来，本节会详细介绍构建业务中台的具体策略：领域驱动、需求结构化和能力可配置。首先，我们通过领域驱动，从整体上划分业务中台的领域，进而划分出业务中台的具体能力中心；其次，对具体的领域进行细化。在这里我们会使用需求结构化和能力可配置两种策略，最终形成易用、灵活的业务能力中心。
3.3.1 领域驱动设计
业务中台的构建，首先需要进行整体规划。对企业而言，中台所涉及的内外部系统交错复杂，而领域驱动设计（Domain-Driven Design，DDD）是厘清这些错综复杂系统的一种实践策略。借鉴领域驱动设计，我们可以梳理业务应用系统所涉及的各角色的旅程地图，包括运营者、消费者、客服、导购等，然后根据用户旅程地图所涉及的业务对象或实体，剥离差异性，抽取共性，最终形成共享的服务能力。
领域驱动设计最早是由Eric Evans提出的，目的是对软件所涉及的领域进行建模，以应对系统规模过大时引起的软件复杂性问题。以领域驱动构建业务中台的过程可以分为战略和战术两大阶段。
1.战略阶段
业务中台建设的战略阶段的核心目的是划分问题域，确定核心领域，整理出限界上下文。领域按照类型可划分为核心领域、支撑子域和通用子域。实现业务愿景和价值的主要系统功能即是核心域，用来支撑核心域的子域称为支撑子域，而相对通用的则称为通用子域。限界上下文为领域提供上下文语境，确保领域内的术语在其特定的边界范围内具有一个没有二义性的含义。领域驱动的业务中台构建过程中，首先从业务维度出发，开发者与领域专家使用通用语言进行信息的沟通及确定，梳理出业务关键的核心域及支撑核心领域的子域。在过程中，也会浮现一些通用系统需求及出于技术维度方面考虑的场景，这就形成了通用子域。
在领域划分的基础上，我们将中台所涉及的业务领域划分为通用能力域及商业能力域（见图3-5）。对于一个系统而言，用户管理、登录认证、消息发送、数据字典等通用功能，可以形成通用能力域。而针对客户互动相关的场景（如消费者浏览商品并下单购买，消费者享受会员权益，平台通过各种促销活动促进交易等），所涉及的商品中心、交易中心、库存中心、会员中心、营销中心等促进商业行为的领域，可以形成业务中台的商业能力域。通用能力域主要关注基础功能性能力，为商业能力域提供基础支持；而商业能力域主要关注各类商业领域能力，以进一步支撑前台业务的多样化场景。
与传统DDD不太一样的是，我们不太强调支撑子域。这是因为中台是企业应用的共享服务平台，它将支撑各色各样的业务应用。从不同的业务应用角度区分核心域和支撑子域是有意义的。但从业务中台的角度，就没太大必要分出哪个是核心域，哪个是支撑子域。当然，我们在业务中台的建设过程中，还是会区分核心域和支撑子域，因为业务中台建设是由业务应用驱动的。
2.战术阶段
在将系统划分为多个能力中心后，中台建设就进入战术阶段。在战术阶段，针对已确定的能力中心，中台要进行具体领域设计。在此阶段，我们会更关注领域内部的要素。我们一般使用领域模型来表达领域知识。常见的领域模型包括实体、值对象、领域服务、领域事件和聚合等。
- 以交易上下文为例（见图3-6），在该限界上下文中，关键核心为交易（Transaction）。
- 交易体现的不只是一个订单，还体现了一个交易动作。
- 一个交易会产生很多种单据，如交易订单（TradeOrder）、支付订单（PayOrder）、发货订单（DeliveryOrder）等。
- 一个交易订单会由一条或多条订单商品信息（OrderItem）组成。这些单据包含对应的单据ID、状态及其他实体属性，它们就是限界上下文的实体。
- 交易上下文中，所有实体、值对象都围绕着交易，而外部需要访问交易上下文，必须从交易开始，所以交易可视作一个交易上下文的聚合根。当一个消费者下单后，首先会创建交易实体，在创建该聚合根实体的过程中，还需要创建对应的多种单据。
- 为了完整构建、初始化交易实体，我们可通过工厂（TransactionFactory）来封装具体的创建逻辑。
每个实体均会涉及状态的改变，而这种状态改变的动作可以触发一个领域事件。领域事件一般是“名词+动词过去式”。消费者下单后将产生一个订单已创建（OrderCreated）的领域事件。对于交易订单实体而言，创建订单属于实体的能力。而下单过程中，需要扣减库存（DeductStock），该动作在交易上下文中涉及了其他上下文的领域对象，所以可以通过领域服务进行协调，进而保证不同上下文的一致性。
综上，在领域驱动设计的过程中，我们通过战略、战术两个阶段，从宏观上整体划分领域边界，将业务中台划分为通用能力域及商业能力域，进而针对每个能力中心，不断细化领域对象，形成丰富的领域对象模型，将领域能力构建成具体业务中心的能力。
