一 背景

在上一篇《业务团队如何统一架构设计风格？》中，探讨了一种业务架构的设计规范，以期达到这些目标：用标准约束技术细节；用技术工具而非文档推行标准；持续重构而非造新轮子；重视业务建模。但通篇表述较为抽象。本篇将总结团队近来的架构演进工作，以更具体的技术细节，详细阐释该理念，作为“统一业务设计风格”的实践篇。文中详述了多个层面的设计规约和基于规约的搭建方式，并在末尾回答了上一篇的诸多疑问。

二 总览

上图以电商产品为例，展示了一套标准框架的各层设计单元。先简单了解下概念，下一章节会详细解释各层的设计规约和搭建方式：

  • 产品模式层

以产品合约描述完整的功能列表；以签署人身份来定位产品功能的适用场景；以合约分组来描述一个独立完备的功能域，分组的集合就是产品功能的范围和边界。通过对合约分组进行组装，可以快速搭建商业产品。

  • 业务模型层

为了减少不同技术同学对领域进行建模的风格差异，我们对业务模型的使用场景做了诸多约定，串联起仓储管理/业务流程/业务组件等基础模块。所有人更关注于业务在模型上的表达，而大大减少了对实现细节的关注。基于对领域的分析，可以快速搭建业务模型。

  • 业务流程层

用一套标准的业务流程框架，描述业务模型的完整执行流程：业务组件是一套高内聚的业务功能集合，基于组件配置将业务模型的信息适配为标准参数，交由基础设施执行具体功能；流程引擎负责创建和管理流程实例，接收指令来触发组件动作的执行，并实现状态推进/条件跳转和异常处理等分支管控的需求。通过对业务组件/基础设施的抽象和沉淀，可以快速搭建业务流程。

  • 数据视图层

用一套标准的数据流机制，来满足视图层的定制化需求：数据流订阅器用于采集数据，物理来源包含区块链跨链数据/业务DB数据/文件系统数据/离线任务数据等；数据流消费器用来加工原始数据，生成展示层数据/待核对数据/数据指标等等。订阅器确保了数据来源的稳定和低成本的快速接入，消费器则交由技术同学自行定制业务逻辑。在不干扰领域建模的基础上，可以快速搭建数据视图。

三 规约详解

1 产品模式

产品合约

1）规约

产品合约以全局视角，描述完整的业务模式，包括：服务的目标客户，依赖的业务领域，输出的服务等等

产品合约的内容是一份静态描述文件，需要由签署身份列表来界定使用场景

2）实例

以电商产品为例，商家单独签署的产品合约被作为商家合约，描述了商品的上架要求；商家+平台+买家共同签署的产品合约，则适用于交易下单场景。

3）搭建

  • 新增/修改低代码：基于业务需求，在产品中心设计产品模板，明确合约分组和具体内容
  • 使用：接入时编码，一次性：在业务系统内编写对应产品合约和签署身份的模型类，完成和产品中心的对接，包括合约的创建/失效，基于签署身份的合约查询等等

合约分组

1）规约

  1. 合约分组以局部视角，描述某个高度内聚的业务领域所提供的功能和依赖的配置信息，包括：业务模型，业务服务，业务流程，业务组件等等
  2. 多个合约分组共同组成一个可交付业务的产品合约

2）实例

电商产品合约下，商品分组描述了商品上架的流程和配置，下单分组约束了订单创建的流程和服务信息，退货分组则说明了退货流程和买家能够享受的客户服务。

3）搭建

  • 新增/修改低代码：以元数据的方式定义一个合约分组，包含模型/流程/配置等等，每一个配置都可以用键路径/配置值类型和限制等描述
  • 使用硬编码：在业务系统内定义合约分组的模型类，完成与产品合约内容交互的写入和读取，在业务代码处显式获取业务分组实例低代码：搭建合约查询->分组解析->配置获取的通用框架(引入缓存避免重复查询)，业务层只需要通过元数据描述，就可以获取对应分组内的配置信息

2 业务领域

模型

1）规约

  1. 业务模型描述一个领域内的核心业务实体，是唯一贯通业务流程和业务组件的业务实例
  2. 一个业务模型内可以关联其他模型，但应避免出现循环依赖
  3. 一个完备的业务模型描述需要包含：数据模型，视图模型，业务模型/数据模型/视图模型的三者转换，业务模型仓储等

2）实例

退货业务，基于退货单推进业务流程，各业务组件从退货单获取必要的业务信息，执行退货/退款/通知等业务功能；退货单关联自一个正向订单，但正向订单不可反向依赖退货单；一个退货单模型对应一张主单据表和多张退货明细表，仓储需要负责完成业务模型数据模型的双向读写

3）搭建

  • 硬编码：编写业务模型(Model)/数据模型(DO)/数据交互(Mapper)/视图模型(VO)/转换层(Converter)/仓储(Repository)等等
  • 低代码：用元数据描述，自动生成DO/VO/Mapper/Converter；基于底座提供的仓储组件，也可以通过元数据描述，自动生成业务模型仓储的实例

服务

1）规约

1、业务服务是一套以业务领域为单位(interface)作聚合，开放给内外所有使用方的最小业务功能单元(method)

2、业务服务需要一套定义规范(annotation/aop等)，对每一个功能单元有清晰直观的元数据描述，用以实现服务发现/文档生成/权限管控/稳定性保障等等。元数据包括：业务域，业务动作，读/写，错误码范围，返回值模型等等

3、业务服务的入参，限制为一个sysParam和一个bizParam，前者为调用来源/幂等ID/产品码/租户ID等系统参数，后者为各业务自行定义的模型参数，建议为可全链路透传(rpc->api->flow->component)的POJO

4、业务服务以Result形式返回，错误码尽量控制在元数据描述的范围内，不泄漏任何exception给调用方。返回的业务信息，建议为POJO或VO

5、业务服务不局限于调用方的物理来源，只需要在对接层增加简单的转换逻辑，做授权管控即可

6、写服务的实现，需要有事务管理机制

2）实例

public interface DemoOrderService {    /**     * 下单申请     * @param sysParam sysParam     * @param bizParam bizParam     * @return result     */    @ApiFunction(apiType = ApiType.SUBMIT, funcBiz = "ORDER",funcAction = "APPLY",            returnType = OrderApplyResponse.class, errorCodeType = CommonErrorCodeEnum.class)    CommonResult apply(ApiReqSysParam sysParam, OrderApplyInfo bizParam);}

3）搭建

  • 新增/修改定义-低代码：基于元数据描述，自动生成interface+method+errorcode+POJO等等
  • 实现硬编码：简单需求/不可模板化/无法流程化的业务需求，直接编码低代码：对于标准的流程发起服务(申请上架/申请下单/申请退货)，用模板实现合约分组加载->流程配置加载->流程初始化(幂等)->流程触发->结果处理；对于标准的流程推进服务(通知回执/调度推进)，用模板实现流程配置加载->流程触发->结果处理等等。随着更多服务场景的出现，可以有更多模板化的业务服务。
  • 使用硬编码：与所有interface的使用一样，组装请求->调用->处理结果低代码：基于元数据描述和业务配置，将当前业务对象/外部参数映射为服务入参的POJO，异常处理模板化，成功返回的结果以同样方式映射回业务对象或外部响应

流程

1）规约

1、Flow用于描述一个完整的业务流程，基于单个业务模型，推进一个或多个业务子环节

2、对于单个业务模型的同一类型业务流程，可以有多个Flow定义，以满足不同业务模式的定制需求

3、Flow包含迁转 (transition) ，组件 (component) 和动作 (action) 三级结构，运作原理如下：每次触发 (operate) 对应于组件的一次action，所有action都成功的component会完结，而所有component都成功的transition将会触发Flow和业务模型的状态迁转。

4、Flow的目标是将复杂流程拆解成多个原子化的业务动作，相互解耦

5、Flow需要结合业务服务/消息/调度等调用入口的触发，才能实现完备的流程推进

6、Flow需要依赖外部调用方提供事务管理机制(通常是业务服务)，需要依赖业务模型仓储来控制模型的加载和存储

2）实例

3）搭建

  • 新增/修改低代码：Flow自身的运作由底座组件支撑，只需一次性编码；若需要定义业务流程，可基于业务组件模板和业务模型，动态生成Flow配置文件；加上版本控制和隔离机制，就可以防止兼容性问题
  • 使用硬编码：Flow初始化场景，从当前业务领域的合约分组中，获取需要的Flow配置，初始化流程并推进；Flow推进场景，基于modelId+modelType+operate+request，可以用模版化代码自动触发低代码：通过对合约分组中Flow配置的标准化，可以将Flow初始化场景也以模板化的方式实现；当一个现有业务服务需要支持新定制的业务流程时，只需调整合约内的配置即可

组件

1）规约

1、业务组件是某一类业务动作的聚合，面向业务功能设计，不局限于任何一个业务模型

2、业务组件的业务动作，是原子化的最小业务单元，粒度暂无强制要求，但以解耦和复用程度为衡量依据；建议其依赖一个到多个基础设施/业务服务，以模板化的方式提供标准的业务动作实现

3、对于某个业务模型，业务组件通过开放适配器(详见【基础设施-适配】)的方式支持受控定制，或以完全复写的方式实现排他定制(不允许其他业务复用)

4、所有的核心业务逻辑，都应收归到业务组件层及其以下(无流程的简单业务服务除外)，包括但不限于：参数校验，业务校验，重入/幂等控制，业务模型变更，合约分组变更，计算规则，外部服务交互等等

5、业务组件需要一套定义规范(xml/annotation等)，对其支持的业务动作和业务模型有清晰直观的元数据描述，用以搭建业务流程。元数据包括：业务动作列表和对应的触发点(operate)，支持的业务模型列表

2）实例

  • 核身组件定义类
public interface BizModelDiscountComponent extends BizModelComponent {    /**     * 占用优惠     * @param context     */    void occupy(FlowContext context);    /**     * 退回优惠     * @param context     */    void refund(FlowContext context);}
  • 核身组件元数据配置

  • 核身组件模板化实现

适配器Adapter的解释，详见【模型适配】小节

public abstract class AbstractBizModelDiscountComponent implements BizModelDiscountComponent {    @Resource    private DiscountApiService discountApiService;    @Override    public void occupy(FlowContext context) {        // TODO AdapterConfigInfo根据context从当前合约中获取        T bizModel = (T) context.getBizModel();        getDiscountAdapter().processOnOccupyResult(                bizModel,                discountApiService.occupy(getDiscountAdapter().toOccupyInfo(bizModel, new AdapterConfigInfo()))        );    }    @Override    public void refund(FlowContext context) {        // TODO AdapterConfigInfo根据context从当前合约中获取        T bizModel = (T) context.getBizModel();        getDiscountAdapter().processOnRefundResult(                bizModel,                discountApiService.refund(getDiscountAdapter().toRefundInfo(bizModel, new AdapterConfigInfo()))        );    }    @SuppressWarnings("unchecked")    protected BizModelToDiscountAdapter getDiscountAdapter(){        return (BizModelToDiscountAdapter) FlowInstanceFactory.instanceBizAdapter(                "DISCOUNT", (Class原文链接
本文为阿里云原创内容，未经允许不得转载。