mituxiaoshami / treasure-mall

treasure-mall

基于COLA 4.0的后端项目脚手架

模块介绍

treasure-mall-api

对应的是COLA的client层，提供服务的模块，借用领域专用语言 （DSL） 设计的一套API，目的有以下两个：

1. API的收口，以前是不同的服务提供在不同的类中，散落无序，这对外部的服务使用方还是服务的提供方都是不利于整理的，使用这套API能让散落在不同地方的API能收口到同一个地方
2. 对于API的业务理解成本降低，方便理解API的含义以及目的

有利就有弊，同样的，为了用领域专用语言 （DSL） 而带来的劣势：

1. 开发成本：这一套API对应的通用语言需要在团队内部达成共识，这一阶段的开发成本避免不了
2. 维护成本：好用也意味着复杂，对这套API的理解成本，维护成本等等都比原来的restful或者其他API暴露方式成本高

treasure-mall-components

项目组件模块，目前主要包含了以下内容

并发执行器

disruptor

Exception

对不同异常的封装，以及异常的统一

log

这个组件目的是优雅的记录操作日志：

业务操作日志几乎存在于每个系统中，操作日志的目的是让系统客户简单易懂的理解系统使用历史，所以不能像系统日志一样难于理解，所以这个组件的目的有以下几个方面：

1. 简单易懂，易于理解
2. 操作日志不和业务逻辑解耦
3. 接入使用简单

解耦：采用AOP+SpEL的方式记录日志

convert

这块主要是对模型之间的转换，包括DTO转换成TO，或者Domain转换成DTO等等

treasure-mall-start

项目启动模块，不依赖任何其他模块，只做项目的启动

treasure-mall-test

项目测试模块，这个模块不在 COLA 4.0 架构规范中，但把测试单独划为一个模块我觉得是有必要的，理由如下：

1. 保证提测质量，做到影响范围可控，提高项目的质量
2. 用例的沉淀，保障项目后期技改不影响业务
3. 减少测试回归的工作量，团队之间和谐融洽

基于以上三点：在经过一系列的调研和选型之后，我选择了 Cucumber 测试框架，理由如下：

1. 传统的junit测试框架不利于场景测试，比如一个功能点影响另外一个功能点，那么就需要在一个方法中去调用另外一个方法，如果影响范围越来越广，那么方法的复杂度会越来越不可控
2. 对于用例的维护，在junit中，一个单测方法就是一个用例，那么如果一个业务有几百个用例，就需要几百个方法，如果对这块业务有改动，几百个方法一个个点过去也太吃力了

所以基于以上两点：我选择了 Cucumber 作为测试框架