基于COLA 4.0的后端项目脚手架
对应的是COLA的client层,提供服务的模块,借用领域专用语言 (DSL)
设计的一套API,目的有以下两个:
- API的收口,以前是不同的服务提供在不同的类中,散落无序,这对外部的服务使用方还是服务的提供方都是不利于整理的,使用这套API能让散落在不同地方的API能收口到同一个地方
- 对于API的业务理解成本降低,方便理解API的含义以及目的
有利就有弊,同样的,为了用领域专用语言 (DSL)
而带来的劣势:
- 开发成本:这一套API对应的通用语言需要在团队内部达成共识,这一阶段的开发成本避免不了
- 维护成本:好用也意味着复杂,对这套API的理解成本,维护成本等等都比原来的restful或者其他API暴露方式成本高
项目组件模块,目前主要包含了以下内容
对不同异常的封装,以及异常的统一
这个组件目的是优雅的记录操作日志:
业务操作日志几乎存在于每个系统中,操作日志的目的是让系统客户简单易懂的理解系统使用历史,所以不能像系统日志一样难于理解,所以这个组件的目的有以下几个方面:
- 简单易懂,易于理解
- 操作日志不和业务逻辑解耦
- 接入使用简单
解耦:采用AOP+SpEL的方式记录日志
这块主要是对模型之间的转换,包括DTO转换成TO,或者Domain转换成DTO等等
项目启动模块,不依赖任何其他模块,只做项目的启动
项目测试模块,这个模块不在 COLA 4.0 架构规范中,但把测试单独划为一个模块我觉得是有必要的,理由如下:
- 保证提测质量,做到影响范围可控,提高项目的质量
- 用例的沉淀,保障项目后期技改不影响业务
- 减少测试回归的工作量,团队之间和谐融洽
基于以上三点:在经过一系列的调研和选型之后,我选择了 Cucumber
测试框架,理由如下:
- 传统的junit测试框架不利于场景测试,比如一个功能点影响另外一个功能点,那么就需要在一个方法中去调用另外一个方法,如果影响范围越来越广,那么方法的复杂度会越来越不可控
- 对于用例的维护,在junit中,一个单测方法就是一个用例,那么如果一个业务有几百个用例,就需要几百个方法,如果对这块业务有改动,几百个方法一个个点过去也太吃力了
所以基于以上两点:我选择了 Cucumber
作为测试框架