一  背景

二  总览

• 产品模式层

• 业务模型层

• 业务流程层

• 数据视图层

三  规约详解

1  产品模式

产品合约

1）规约

1. 产品合约以全局视角，描述完整的业务模式，包括：服务的目标客户，依赖的业务领域，输出的服务等等
   
   
2. 产品合约的内容是一份静态描述文件，需要由签署身份列表来界定使用场景

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）规约

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<OrderApplyResponse> 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）实例

<?xml version="1.0" encoding="UTF-8"?>
<flow id="OrderApply" version="001" desc="标准下单流程">    <config>        <model class="xxx.xxx.Order"/>    </config>    <init type="INIT" desc="初始化">        <action operate="INIT.INIT"/>    </init>    <transitions>        <transition from="INIT" to="ITEM_OCCUPIED">            <component type="ITEM" desc="扣减库存">                <action operate="ITEM.OCCUPY"/>            </component>        </transition>        <transition from="ITEM_OCCUPIED" to="DISCOUNT_OCCUPIED">            <component type="DISCOUNT" desc="扣减优惠">                <action operate="DISCOUNT.OCCUPY"/>            </component>        </transition>        <transition from="DISCOUNT_OCCUPIED" to="SUCCESS">            <component type="NOTIFY" desc="下单成功通知">                <action operate="NOTIFY.SELLER"/>                <action operate="NOTIFY.BUYER"/>                          </component>        </transition>    </transitions></flow>

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<T extends BizModel> extends BizModelComponent<T> {
    /**     * 占用优惠     * @param context     */    void occupy(FlowContext context);
    /**     * 退回优惠     * @param context     */    void refund(FlowContext context);}

• 核身组件元数据配置

<componentTemplate type="DISCOUNT" desc="优惠">    <interface name="xxx.xxx.BizModelDiscountComponent"/>    <bizModelMappings>        <bizModelMapping>            <bizModel class="xxx.xxx.Order"/>            <componentEntry name="orderDiscountComponent"/>        </bizModelMapping>        <bizModelMapping>            <bizModel class="xxx.xxx.RefundOrder"/>            <componentEntry name="refundOrderDiscountComponent"/>        </bizModelMapping>    </bizModelMappings>    <triggerMappings>        <triggerMapping>            <triggerTemplate operatePostfix="OCCUPY"/>            <methodEntry name="occupy"/>        </triggerMapping>        <triggerMapping>            <triggerTemplate operatePostfix="REFUND"/>            <methodEntry name="refund"/>        </triggerMapping>    </triggerMappings></componentTemplate>

• 核身组件模板化实现

public abstract class AbstractBizModelDiscountComponent<T extends BizModel> implements BizModelDiscountComponent<T> {    @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<T> getDiscountAdapter(){        return (BizModelToDiscountAdapter<T>) FlowInstanceFactory.instanceBizAdapter(                "DISCOUNT", (Class<? extends BizModel>) TypeUtils.getRealClassOfParameterizedType(this));    }}

3）搭建

• 新增/修改

• 硬编码：全新业务组件基本无法低代码化，需要开发有足够的设计思维和大局观，权衡复用度和成本后实现初版；随着业务发展，逐步抽象出模板化的业务组件实现；很多场景下，如果避免不了复杂的定制逻辑，可以自行以策略/职责链/工厂等多种设计模式落地，这依赖于开发者的建模能力，不做强制要求
• 
  
• 低代码：已有的业务组件应用于新业务模型的场景，如果已经抽象出合约配置+适配器+基础设施的标准模板，只需做合约配置即可(通知/核身/存证上链等场景适合)
• 
  

• 使用

• 低代码：在Flow底座中完成业务组件的编排/发现和触发，一次性编码；完成Flow配置，即完成业务组件的装配
• 
  

3  基础设施

规约

1. 基础设施是一套以高复用高内聚低变化的外部服务能力为单位(interface)作聚合，开放给业务服务/业务组件使用的最小功能单元(method)
   
   
2. 基础设施可以是对渠道能力的封装，如外部商家渠道服务/跨境渠道服务等；也可以是对通用技术能力的封装，如优惠服务/商品服务/客户服务等
   
   
   
   
3. 基础设施和业务服务的差异在于：前者的核心功能通常由外部服务提供，在当前系统内的核心职责是参数组装/场景识别/返回解析和异常处理
   
   
   
   
4. 基础设施的定义不依赖于外部服务，入参为自行定义的标准POJO，返回值同样以Result封装，屏蔽外部服务的exception和业务异常，业务返回同样是标准POJO

实例

• 基础设施-信息通知

public interface NotifyGateway {
    /**     * 通知(邮件/短信/站内信)     * @param notifyInfo     * @return     */    CommonResult<NotifyResponse> notify(NotifyInfo notifyInfo);}

搭建

• 新增/修改

• 硬编码：基础设施的接入通常是一次性的，低代码的价值不易发挥
• 
  

• 使用

• 硬编码：在业务服务/业务组件等调用方代码中，组装入参->调用->解析返回
• 
  
• 低代码：在业务组件中，基于下文将介绍的适配机制，可以实现：合约配置+模板化业务组件，低代码复用现有基础设施
• 
  

4  模型适配

规约

1. 模型适配用于衔接业务模型和基础设施/业务服务，实现模型->入参和返回->模型的双向处理
   
   
2. 在模板化的业务组件中，适配器和基础设施/业务服务的调用链已经固化，各业务模型的组件实例只需要实现对应的适配器，即可完成业务定制
   
   
3. 适配器通常与产品合约配置结合，描述业务模型->基础设施/业务服务入参的映射关系

实例

• 适配器-业务模型->网银签名

public abstract class BizModelToDiscountAdapter<U extends BizModel> implements BizModelAdapter<U> {    @Override    final public String getType(){        return "DISCOUNT";    }    /**     * 生成扣减申请     * @param bizModel     * @return     */    abstract public OccupyInfo toOccupyInfo(U bizModel, AdapterConfigInfo configInfo);
    /**     * 处理扣减结果     * @param bizModel     * @param result     */    abstract public void processOnOccupyResult(U bizModel, CommonResult<OccupyResponse> result);
    //...}

• 订单模型Order，需要使用优惠扣减服务时，需要实现适配器BizModelToDiscountAdapter：

@BizAdapterpublic class OrderToDiscountAdapter extends BizModelToDiscountAdapter<Order> {    @Override    public List<ConfigDef> getConfigDefs() {        return Lists.newArrayList(                ConfigEnum.DISCOUNT_TYPE,                ConfigEnum.DISCOUNT_TERM        );    }
    @Override    public OccupyInfo toOccupyInfo(Order bizModel, AdapterConfigInfo configInfo) {        // 解析出客户选择的优惠类型        return new OccupyInfo();    }
    @Override    public void processOnOccupyResult(Order bizModel, CommonResult<OccupyResponse> result) {        // TODO 根据扣减成功的优惠,重新计算订单金额    }
    // ...}

搭建

• 新增/修改

• 定义-硬编码：当业务组件和基础设施/业务服务出现调用关系时首次定义，通常不再变更
• 
  
• 实现-低代码：可以用一套灵活的合约配置描述映射关系，实现一次编码后只需配置维护；但是，这既依赖于DSL级别的描述能力，也需要业务模型和基础设施/业务服务的设计者，都具备较高的抽象能力，成本较高
• 
  

• 使用

• 硬编码：当业务开发抽象出可模板化的业务组件时，即完成了首次接入；当基础设施/业务服务出现新模式时，需要进行适配调整

四  总结

1  业务设计规范体现在哪里？

2  业务设计只有合适没有标准，为何要强制规范？

3  如何快速支撑业务，研发效能提升体现在哪里？

1. 业务模型：是否需要新的业务模型，是否需要调整现有模型
2. 业务服务：xxxxxxxxxxxx业务服务，xxxxxxxxxxxx现有服务

3. 业务流程：xxxxxxxxxxxx业务流程，xxxxxxxxxxxx现有流程
4. 业务组件：xxxxxxxxxxxx业务组件，xxxxxxxxxxxx现有组件

5. 基础设施：xxxxxxxxxxxx基础设施，xxxxxxxxxxxx现有设施
6. 产品合约/合约分组：基于上述判断，评估产品合约和合约分组的组装

大数据可视化DataV课程

点击阅读原文了解详情