简洁应用框架VSEF - 业务解构模版

简洁应用框架VSEF - 业务解构模版_第1张图片

当一个应用系统上部署多个“业务模块”的时候,我们期望有一个统一的结构模版,这个结构模版是“业务架构”和“技术架构”的一个重要衔接,本文就是对这个结构模版的一些探索。

简洁应用框架VSEF - 业务解构模版_第2张图片

原型


  结构设计

先回顾一下《简洁应用框架VSEF的架构》中提到的总体结构。

简洁应用框架VSEF - 业务解构模版_第3张图片

VSEF 总体结构

  结构样例

模块:

  1. 客户端:vsef-archetypes-client

  2. 业务逻辑:vsef-archetypes-application



vsef-archetypes-application 目录结构:

简洁应用框架VSEF - 业务解构模版_第4张图片

原型目录结构截图如下:

简洁应用框架VSEF - 业务解构模版_第5张图片

原型目录结构截图

  执行模版

业务流程 l3.process 处理背后,可以考虑一些共性的东西,作为模版,减少重复工作,常见的一些点有:

  1. 异常如何处理

  2. 是否有幂等需要

  3. 是否需要并发加锁

  4. 是否需要提供组件协议

  5. 是否有数据库和消息操作

  6. .......



在原型示例处理流程中,继承了处理模版。

简洁应用框架VSEF - 业务解构模版_第6张图片

示例处理流程继承处理模版

这个模版里面植入了“幂等校验与处理”的抽象。

简洁应用框架VSEF - 业务解构模版_第7张图片

处理模版中抽象了“幂等校验与处理”逻辑

【延伸扩展】下面是V2交易框架中的一个比较复杂的处理模版,可以作为抽象的大图参考。

  模型抽象

除了处理过程的抽象,我们有时也会都处理的上下文进行抽象,可以节省各个流程的转换过程。

因为我们处理模版中,没有非常复杂的具体逻辑包装,同时为了不对使用者提供太多约束,所以模型只是简单的输入 Request、输出 Result 抽象。

简洁应用框架VSEF - 业务解构模版_第8张图片

原型中处理模版对模型的抽象

但是,随着业务活动的增多,是可以进一步细化,但这也意味着通用性会降低,这不应该属于通用框架的部分,会属于具体落地的效能讨论主题,这里就不展开了。

【延伸扩展】下面会展示一下V2里面的最终模型模型逻辑,可以做为后续设计的一个参考。

简洁应用框架VSEF - 业务解构模版_第9张图片

案例


  价保 priceinsurance


  • 场景介绍

主要功能:基于下单的订单信息,重新请求营销等系统,计算当前价格和价差,进行赔付。

简洁应用框架VSEF - 业务解构模版_第10张图片

V2 价保业务活动分析

  • 原型结构

原型选取4个入口案例:申请价保服务、提交价保服务、申请并提交服务、异步check消息处理。

主要的结构如下图所示:

简洁应用框架VSEF - 业务解构模版_第11张图片

价保原型功能结构大图

  • 关注点

业务活动组合

价保中有个场景是“申请并提交价保服务”,这个服务需要结合“渲染价保服务”、“申请价保服务”。这里的处理策略可能有这样几种:

  1. Process独立:新写一个“申请并提交价保处理流程”,独立编排。

  2. Process聚合:写一个“申请并提交价保服务”,调用“渲染价保服务”、“申请价保服务” 的 l3.process 服务。

  3. API 聚合:写一个“申请并提交价保服务”,调用“渲染价保服务”、“申请价保服务” 的API实现。

价保中采用的是API聚合,因为除了核心逻辑,比如错误码的转换、限流等,都会包含在API里面,所以为了尽可能得保持逻辑一致,还是在当做黑盒处理比较好,聚合服务不要去理解原子服务背后的具体细节。

抽象模型

价保的模版中,模型的抽象保留了“减少约束”的思想,直接用抽象类型,且无继承约束。

简洁应用框架VSEF - 业务解构模版_第12张图片

价保的处理模版模型抽象约束为无



这样做有个非常舒服的案例是“异步check”消息的处理,可以直接使用消息处理的上下文,作为Request和Result,减少了转换陈本。当然,这会造成很难复用活动节点,这里采用服务脚本直连能力的方法是比较好的。但是在模型抽象层面的思考还是有意义的。

简洁应用框架VSEF - 业务解构模版_第13张图片

使用消息输入输出作为处理流程的上下文

业务身份能力

价保有个业务身份能力,需要计算业务身份实例,用于后面的扩展寻找插件。这里业务身份的策略是:follow下单时的业务身份。

简洁应用框架VSEF - 业务解构模版_第14张图片

价保业务身份计算能力

扩展服务机制

扩展作为一种服务,其扩展机制是可以自定义的。

在价保原型中,会议一些校验、价差计算、渲染的业务扩展,为了支持这些扩展,扩展区域主要设计了几个模块:

  1. ext - 扩展服务模块 :扩展服务的实现,负责寻找插件,回收结果。

  2. plugins - 插件模块:实现业务扩展的插件,可以托管在应用代码库内,也可以通过二方包方式集成进来。

  3. sdk - 扩展SDK模块:模型和方法定义,作为衔接 ext 扩展服务 和 plugins 插件实现的桥梁。

简洁应用框架VSEF - 业务解构模版_第15张图片

价保扩展服务设计

  拼团 groupon
  • 场景介绍

主要功能:招商侧可提报优惠、团信息;下单时,基于设置信息进行hold订单,当支付订单数达到成团人数,则拼团成功,创建物流单;否则,拼团超时失败,快速退款,关闭订单。

简洁应用框架VSEF - 业务解构模版_第16张图片

拼团业务活动分析

  • 原型结构

原型选取2个入口案例:订单支付消息、拼团查询服务。

主要的结构如下图所示:

简洁应用框架VSEF - 业务解构模版_第17张图片

拼团原型功能结构大图

  • 关注点

业务脚本

拼团原型中,有一个查询的case。这个case中,直接使用了业务脚本服务,在业务脚本中调用了 l5.ability 中的数据能力获取了数据,并进行了简单转换。

简洁应用框架VSEF - 业务解构模版_第18张图片

拼团查询服务直接使用 l5.ability

子流程串联

拼团的时候,接到付款消息,需要区分开团订单还是参团订单,走不同的处理流程。在“参团or开团流程”中展示了如何串联2个业务脚本。

简洁应用框架VSEF - 业务解构模版_第19张图片

"参团or开团流程" 串联了2个子业务流程

数据操作

拼团和价保都是一样的,操作数据的时候,通过定义依赖接口进行解耦,同时模型会使用业务能力中的“领域模型”,不会直接依赖DO。数据服务,负责理解领域依赖接口,实现数据转换。

简洁应用框架VSEF - 业务解构模版_第20张图片

拼团数据服务不直接依赖DO

简洁应用框架VSEF - 业务解构模版_第21张图片

总结

由于follow原型结构,价保、拼团的项目结构是一样的。如果对这个类似的“应用架构”进行边界定义,当一个应用上部署多个“子业务应用”的时候,可以类比 docker 的思想的,做较多的统一服务(更多的可以是理解层面),也便于新业务模块的快速初始化。与 docker 的差异是,这种抽象程度进一步走进了具体的业务单元。

简洁应用框架VSEF - 业务解构模版_第22张图片

业务应用架构 - 业务逻辑层的“集装箱”

3ba03a40f44d3690911c283dad3684da.png

团队介绍

我们是交易平台-平台产品服务团队。团队主要从事交易链路交付工作,在交付工作中,抽象和建设横向产品能力(如:预售、电子凭证等),团队关注业务架构、DDD等理论与实践,致力于高效、稳定地实现业务接入,并抽象赋能。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

你可能感兴趣的:(简洁应用框架VSEF - 业务解构模版)