支付系统设计二：统一开发框架

支付系统设计二：统一开发框架

2023-05-17 07:29

在开始一个新项目建设，进入开发环节之前，容易忽略一项非常重要的环节。对于代码的编写，是开发人员各展拳脚还是制定约束规范，前置的结果是项目个子系统代码风格各异，开发人员个人能力直接体现到了项目代码中，能力稍微差的项目代码惨不忍睹，后期的维护扩展令人担忧，这种结果是我们都不愿看到的。

对于后者书面的约定规范真的起作用么，也不尽然，就像马路中间树立着禁止穿越马路警示，很多人还是当做没看到，所以最直接的办法就是加栅栏，强制限制，当然翻越栅栏的也不再少数，但是我们已经阻止了多数违规。

所以，在进入开发阶段，我们对新建的项目的各个子系统的应用框架进行统一化，即在系统新建初期就定下项目的分层，以及依赖的包版本，对同一业务场景的统一处理方案，以及最基本的非业务层面的代码逻辑等等，通过层层限制，来规范统一化代码风格，让开发人员集中精力完成系统的业务编写。

本篇将讲述自己在工作中所使用的开发框架以供参考（融入DDD思想）。

按照DDD分层将系统分为四层，基础设施层包含多个模块，其余三层各对应一个模块：
在这里插入图片描述
各模块之间的依赖关系如下：

案例项目实际模块分层如下：

下面以后台配置接口（路由规则条件配置）为例简要介绍下每个模块所包含的包以及各模块职责，对应的后台管理系统页面如下：
在这里插入图片描述
输入配置信息，点击提交，请求到后台的报文如下：

transCode：交易码（业务类型）对应到后台代码枚举如下：

transType：交易类型（增删改查操作）对应到后台代码枚举如下：

一个系统对外提供的接口可以归为两类，提供于，，我们对这两类接口进行收敛，即就只定义两个接口（理想情况下，具体实践还是要依据实际情况）。

接口定义如下：

在这里插入图片描述
控制层抽象类 AbstractController 定义通用处理方法 handle 以及业务方法模板 handleRequestInternal 如下：

请求处理核心方法：preHandle、handleRequestInternal、postHandle

前置处理，构建请求的上下文，并解析上送报文填充到上下文中；
具体业务处理由子类（BackstageController、RuntimeController）实现；
后置处理，构造model，解析视图，渲染视图；

后台管理控制类实现 BackstageController 如下：

在这里插入图片描述

定义Service层操作执行服务接口如下：

后台操作执行服务接口实现 BackstageOperateExecutorServiceImpl 如下：

后台管理系统基础 BackstageOperator 如下：

操作器定义了增删改查方法以及对应的校验方法。

定义 OperateExecutor 如下：

操作执行器实现类图如下：

在这里插入图片描述

定义增加操作执行器 AddExecutor 如下：

即在 BackstageOperateExecutorServiceImpl 中,进行业务处理，

同时在 BackstageOperateExecutorServiceImpl 还有很重要的一部分，参数校验，因为在定义接口的时候没有在方法中定于特定的实体类，使用一些框架注解进行参数校验，所以在入口处没有进行参数校验，这里使用基于YML文件配置方式进行参数校验。

在main层资源配置包下配置参数校验文件：
在这里插入图片描述
如下为路由规则配置新增校验配置：

#路由规则配置新增：ruleConfigadd
#路由规则配置删除：ruleConfigdelete
#路由规则配置修改：ruleConfigmodify
#路由规则配置单笔查询：ruleConfigquery
#路由规则配置列表查询：ruleConfiglist

本案例中报文上送header中对应字段如下

“transCode”: “ruleConfig”,
“transType”: “add”

transCode+transType"=ruleConfigadd，所以对应于Yml中的。

在这里插入图片描述

为了降低参数校验配置的重复工作，我们抽象出style，如果在某项配置新增、修改中有相同的参数，并且校验规则是相同的，则抽取出来，在对应的校验配置文件中只需要引入style中的对应配置即可。
在这里插入图片描述
参数/字段验证器接口实现类图，已经涵盖了日常开发所涉及的参数校验

关于此处使用Yml方式对接口参数进行校验的方式此处不在展开了，后期有机会单独开文章介绍。

后台管理系统规则条件配置操作器具体实现如下：

在这里插入图片描述
domain层主要包括领域模型工厂、实体类、聚合、领域模型仓储、领域服务等包。
在上面RuleConfigOperator中，我们可以看到对于持久化引入了领域模型仓储、仓储两个类：

RuleConfigRepository 规则配置仓储，用于持久化配置信息；RouterRuleDomainRepository 路由领域模型仓储用于校验我们对配置的删除操作是否允许，及是否有路由引用此规则。

注意：领域模型存储仓储定义于domain层仓储定义于dal层，领域模型存储仓储包含多个仓储，如下，包含和。

对于后台管理接口在Infrastructure层主要使用到了Dal层进行数据持久化操作。
在这里插入图片描述
dal层主要包含和数据库对应的实体，以及持久化的repository类。

在这里插入图片描述

如上介绍了那么多内容，此时我们后台管理系统又增加了如下一项页面配置，那么开发需要做什么？
在这里插入图片描述

通过如上5步骤完成了，后台页面的新增配置的功能，虽然代码量并没有减少很多，但是我们的项目整洁性以及后期迁移性得到了极大的保证。

本篇主要以后台管理配置接口简要的介绍了下工作中所使用的统一开发框架结构。

以上就是本篇文章【支付系统设计二：统一开发框架】的全部内容了，欢迎阅览！文章地址：http://www.uqian.cn/news/3092.html
资讯企业新闻行情企业黄页同类资讯首页网站地图返回首页极顶速云移动站 http://m.uqian.cn/ , 查看更多

打赏