网站服务器是指什么,新郑郑州网站建设,经营网站icp备案要求,微信小程序下载app简介#xff1a;在上一篇《业务团队如何统一架构设计风格#xff1f;》中#xff0c;探讨了一种业务架构的设计规范#xff0c;以期达到这些目标#xff1a;用标准约束技术细节#xff1b;用技术工具而非文档推行标准#xff1b;持续重构而非造新轮子#xff1b;重视业…简介在上一篇《业务团队如何统一架构设计风格》中探讨了一种业务架构的设计规范以期达到这些目标用标准约束技术细节用技术工具而非文档推行标准持续重构而非造新轮子重视业务建模。但通篇表述较为抽象。本篇将总结团队近来的架构演进工作以更具体的技术细节详细阐释该理念作为“统一业务设计风格”的实践篇。文中详述了多个层面的设计规约和基于规约的搭建方式并在末尾回答了上一篇的诸多疑问。 作者 | 木沉 来源 | 阿里技术公众号
一 背景
在上一篇《业务团队如何统一架构设计风格》中探讨了一种业务架构的设计规范以期达到这些目标用标准约束技术细节用技术工具而非文档推行标准持续重构而非造新轮子重视业务建模。但通篇表述较为抽象。本篇将总结团队近来的架构演进工作以更具体的技术细节详细阐释该理念作为“统一业务设计风格”的实践篇。文中详述了多个层面的设计规约和基于规约的搭建方式并在末尾回答了上一篇的诸多疑问。
二 总览 上图以电商产品为例展示了一套标准框架的各层设计单元。先简单了解下概念下一章节会详细解释各层的设计规约和搭建方式
产品模式层
以产品合约描述完整的功能列表以签署人身份来定位产品功能的适用场景以合约分组来描述一个独立完备的功能域分组的集合就是产品功能的范围和边界。通过对合约分组进行组装可以快速搭建商业产品。
业务模型层
为了减少不同技术同学对领域进行建模的风格差异我们对业务模型的使用场景做了诸多约定串联起仓储管理/业务流程/业务组件等基础模块。所有人更关注于业务在模型上的表达而大大减少了对实现细节的关注。基于对领域的分析可以快速搭建业务模型。
业务流程层
用一套标准的业务流程框架描述业务模型的完整执行流程业务组件是一套高内聚的业务功能集合基于组件配置将业务模型的信息适配为标准参数交由基础设施执行具体功能流程引擎负责创建和管理流程实例接收指令来触发组件动作的执行并实现状态推进/条件跳转和异常处理等分支管控的需求。通过对业务组件/基础设施的抽象和沉淀可以快速搭建业务流程。
数据视图层
用一套标准的数据流机制来满足视图层的定制化需求数据流订阅器用于采集数据物理来源包含区块链跨链数据/业务DB数据/文件系统数据/离线任务数据等数据流消费器用来加工原始数据生成展示层数据/待核对数据/数据指标等等。订阅器确保了数据来源的稳定和低成本的快速接入消费器则交由技术同学自行定制业务逻辑。在不干扰领域建模的基础上可以快速搭建数据视图。
三 规约详解
1 产品模式
产品合约
1规约
产品合约以全局视角描述完整的业务模式包括服务的目标客户依赖的业务领域输出的服务等等
产品合约的内容是一份静态描述文件需要由签署身份列表来界定使用场景
2实例
以电商产品为例商家单独签署的产品合约被作为商家合约描述了商品的上架要求商家平台买家共同签署的产品合约则适用于交易下单场景。 3搭建 新增/修改 低代码基于业务需求在产品中心设计产品模板明确合约分组和具体内容 使用 接入时编码一次性在业务系统内编写对应产品合约和签署身份的模型类完成和产品中心的对接包括合约的创建/失效基于签署身份的合约查询等等
合约分组
1规约
合约分组以局部视角描述某个高度内聚的业务领域所提供的功能和依赖的配置信息包括业务模型业务服务业务流程业务组件等等多个合约分组共同组成一个可交付业务的产品合约
2实例
电商产品合约下商品分组描述了商品上架的流程和配置下单分组约束了订单创建的流程和服务信息退货分组则说明了退货流程和买家能够享受的客户服务。 3搭建 新增/修改 低代码以元数据的方式定义一个合约分组包含模型/流程/配置等等每一个配置都可以用键路径/配置值类型和限制等描述 使用 硬编码在业务系统内定义合约分组的模型类完成与产品合约内容交互的写入和读取在业务代码处显式获取业务分组实例低代码搭建合约查询-分组解析-配置获取的通用框架(引入缓存避免重复查询)业务层只需要通过元数据描述就可以获取对应分组内的配置信息
2 业务领域
模型
1规约
业务模型描述一个领域内的核心业务实体是唯一贯通业务流程和业务组件的业务实例一个业务模型内可以关联其他模型但应避免出现循环依赖一个完备的业务模型描述需要包含数据模型视图模型业务模型/数据模型/视图模型的三者转换业务模型仓储等
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)CommonResultOrderApplyResponse apply(ApiReqSysParam sysParam, OrderApplyInfo bizParam);
}
3搭建 新增/修改 定义-低代码基于元数据描述自动生成interfacemethoderrorcodePOJO等等 实现 硬编码简单需求/不可模板化/无法流程化的业务需求直接编码低代码对于标准的流程发起服务(申请上架/申请下单/申请退货)用模板实现合约分组加载-流程配置加载-流程初始化(幂等)-流程触发-结果处理对于标准的流程推进服务(通知回执/调度推进)用模板实现流程配置加载-流程触发-结果处理等等。随着更多服务场景的出现可以有更多模板化的业务服务。 使用 硬编码与所有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推进场景基于modelIdmodelTypeoperaterequest可以用模版化代码自动触发低代码通过对合约分组中Flow配置的标准化可以将Flow初始化场景也以模板化的方式实现当一个现有业务服务需要支持新定制的业务流程时只需调整合约内的配置即可
组件
1规约
1、业务组件是某一类业务动作的聚合面向业务功能设计不局限于任何一个业务模型
2、业务组件的业务动作是原子化的最小业务单元粒度暂无强制要求但以解耦和复用程度为衡量依据建议其依赖一个到多个基础设施/业务服务以模板化的方式提供标准的业务动作实现
3、对于某个业务模型业务组件通过开放适配器(详见【基础设施-适配】)的方式支持受控定制或以完全复写的方式实现排他定制(不允许其他业务复用)
4、所有的核心业务逻辑都应收归到业务组件层及其以下(无流程的简单业务服务除外)包括但不限于参数校验业务校验重入/幂等控制业务模型变更合约分组变更计算规则外部服务交互等等
5、业务组件需要一套定义规范(xml/annotation等)对其支持的业务动作和业务模型有清晰直观的元数据描述用以搭建业务流程。元数据包括业务动作列表和对应的触发点(operate)支持的业务模型列表
2实例
核身组件定义类
public interface BizModelDiscountComponentT extends BizModel extends BizModelComponentT {/*** 占用优惠* param context*/void occupy(FlowContext context);/*** 退回优惠* param context*/void refund(FlowContext context);
}
核身组件元数据配置核身组件模板化实现
适配器Adapter的解释详见【模型适配】小节
public abstract class AbstractBizModelDiscountComponent T extends BizModel implements BizModelDiscountComponent T {Resourceprivate DiscountApiService discountApiService;Overridepublic void occupy(FlowContext context) {// TODO AdapterConfigInfo根据context从当前合约中获取T bizModel (T) context.getBizModel();getDiscountAdapter().processOnOccupyResult(bizModel,discountApiService.occupy(getDiscountAdapter().toOccupyInfo(bizModel, new AdapterConfigInfo())));}Overridepublic 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 基础设施
注此处的基础设施与DDD中的概念有很大差异请勿混淆
规约
基础设施是一套以高复用高内聚低变化的外部服务能力为单位(interface)作聚合开放给业务服务/业务组件使用的最小功能单元(method)基础设施可以是对渠道能力的封装如外部商家渠道服务/跨境渠道服务等也可以是对通用技术能力的封装如优惠服务/商品服务/客户服务等基础设施和业务服务的差异在于前者的核心功能通常由外部服务提供在当前系统内的核心职责是参数组装/场景识别/返回解析和异常处理基础设施的定义不依赖于外部服务入参为自行定义的标准POJO返回值同样以Result封装屏蔽外部服务的exception和业务异常业务返回同样是标准POJO
实例
基础设施-信息通知
public interface NotifyGateway {/*** 通知(邮件/短信/站内信)* param notifyInfo* return*/CommonResultNotifyResponse notify(NotifyInfo notifyInfo);
}
搭建 新增/修改 硬编码基础设施的接入通常是一次性的低代码的价值不易发挥 使用 硬编码在业务服务/业务组件等调用方代码中组装入参-调用-解析返回低代码在业务组件中基于下文将介绍的适配机制可以实现合约配置模板化业务组件低代码复用现有基础设施
4 模型适配
规约
模型适配用于衔接业务模型和基础设施/业务服务实现模型-入参和返回-模型的双向处理在模板化的业务组件中适配器和基础设施/业务服务的调用链已经固化各业务模型的组件实例只需要实现对应的适配器即可完成业务定制适配器通常与产品合约配置结合描述业务模型-基础设施/业务服务入参的映射关系
实例
适配器-业务模型-网银签名
public abstract class BizModelToDiscountAdapter U extends BizModel implements BizModelAdapter U {Overridefinal 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
BizAdapter
public class OrderToDiscountAdapter extends BizModelToDiscountAdapter Order {Overridepublic List ConfigDef getConfigDefs() {return Lists.newArrayList(ConfigEnum.DISCOUNT_TYPE,ConfigEnum.DISCOUNT_TERM);}Overridepublic OccupyInfo toOccupyInfo(Order bizModel, AdapterConfigInfo configInfo) {// 解析出客户选择的优惠类型return new OccupyInfo();}Overridepublic void processOnOccupyResult(Order bizModel, CommonResult OccupyResponse result) {// TODO 根据扣减成功的优惠,重新计算订单金额}// ...
}
搭建 新增/修改 定义-硬编码当业务组件和基础设施/业务服务出现调用关系时首次定义通常不再变更实现-低代码可以用一套灵活的合约配置描述映射关系实现一次编码后只需配置维护但是这既依赖于DSL级别的描述能力也需要业务模型和基础设施/业务服务的设计者都具备较高的抽象能力成本较高 使用 硬编码当业务开发抽象出可模板化的业务组件时即完成了首次接入当基础设施/业务服务出现新模式时需要进行适配调整
四 总结
啰嗦了这么多为避免被过度细节冲淡主题。最后以几个问题做个小结
1 业务设计规范体现在哪里
架构层面从产品合约-业务领域-基础设施我们对应用做了模块拆解在不同层面设计了业务规约约束了各模块的职责技术层面通过多个底座组件一定程度上实现了平台和业务定制的隔离限制了业务细节的无序散布。
2 业务设计只有合适没有标准为何要强制规范
规范的目的不是标准本身本文提出的标准也未必适合所有问题域。想传达的是团队内需要有业务设计的某种共识和沉淀在每次迭代需求和每次项目产出的基础上持续积累持续重构持续优化这对新人融入/个人成长和团队协作都很有帮助。
3 如何快速支撑业务研发效能提升体现在哪里
需要明确的是对于全新的业务需求不会带来明显的效能提升甚至会为了满足设计规范带来一定程度的额外成本。但当多人协作工作交接或是现有功能部分可复用的场景下会减少很多不必要的沟通和维护成本。举例来说当一个业务需求出现时研发人员需要做如下判断
业务模型是否需要新的业务模型是否需要调整现有模型业务服务xxxxxxxxxxxx业务服务xxxxxxxxxxxx现有服务业务流程xxxxxxxxxxxx业务流程xxxxxxxxxxxx现有流程业务组件xxxxxxxxxxxx业务组件xxxxxxxxxxxx现有组件基础设施xxxxxxxxxxxx基础设施xxxxxxxxxxxx现有设施产品合约/合约分组基于上述判断评估产品合约和合约分组的组装
带来的效能提升有这样几点业务领域的每个模块互相解耦研发过程并行化投入人员11可以2改造范围更易于定位资源评估更为准确进度把控更加清晰针对频繁变动且成本过高的模块进行针对性的重构影响范围可控上文中的很多处规约都有潜在的低代码化可能能进一步提升搭建效率。
原文链接 本文为阿里云原创内容未经允许不得转载。
