一个地图小程序的后端项目
很久没写文章了,做这个项目的目的-利用业余时间沉淀技术经验,准备一个好用的脚手架,同时尝试一些在工作中想用但是没机会用的技术
Gi
tHub地址:
https://github.com/mapcoding-cn/preferential-map (
查看原文,欢迎star)
技术方面的简单介绍
在这个项目使用了DDD分层架构提供服务,拆箱即用
主要组件:Spring boot +
mybatis plus + mysql + wechat
数据库技术: mysql使用了空间索引 全文索引 JSON类型等
脚手架中践行的架构理念
领域模型
app: 项目入口和构建,配置文件和资源,不侵入业务
test: 单元测试和非正式代码入口,不打包,不上线[新增]
web: 展示层,发布web接口,处理业务无关的请求入参和异常(=controller+VO),不侵入业务
biz: 应用层,for具体应用的业务逻辑,应对业务易变性,避免非核心逻辑污染core层(BO DTO)
业务流程编排和集成
入出参转换,接口适配
安全认证,权限控制
切面功能如日志拦截
应用级异常的处理
调度job入口(不含业务逻辑)
消息订阅入口(不含业务逻辑)
流程引擎功能(不含业务逻辑)
业务报警功能
业务统计分析功能
其他和业务运行无关的模块
怎么写应用层?有以下几个原则,看下是否符合
core: 核心领域层,针对核心业务抽象建模,反映基本业务现实,需保持一定程度的稳定性(BO DTO)
和biz的区别,只关心核心业务
业务无关的附着功能剥离到应用层实现
infras: 基础设施层,封装项目的基础能力,工具性的,业务无关的
util:静态工具类,封装通用工具,如HttpUtils DateUtils.
enum 枚举类
constant 常量类
exception 异常类
annotion 注解类
model: 公用的bean,各领域对象放到各层里面去实现
config: 全局的工具性配置在放在这里
infras-dal:数据访问层,封装数据库 redis等数据能力,(=dao层+DO),禁止做任何业务加工
infras-facade:对外接口层,定义对外接口,一般是rpc调用的二方包
infras-integration:对内客户端层,对引用外部服务进行统一封装,做接口防腐和适配
infras-common:
eg
开发一个查询接口,对地理对象进行检索,基本数据模型为点集
web: 发布接口/query,进行入参校验 错误码处理 封装VO,调用biz层,这是展示层
biz: 点和线是不同类型要素,Point/Line,调用core层查询并分别处理为Point/Line,这是应用层
core: 封装点集查询逻辑,调用dal层,用数据库或缓存,建立查询索引等,这是核心业务层
infras基础设施能力
dal: mybatis支持的数据访问层,仅做工具性查询,关注sql,redis指令等,这是数据访问层
facade: 对外接口模型,有业务依赖Rpc服务,这里写接口,交由biz层实现,发布为二方库
integration: core查询依赖web服务做关联,这里封装客户端服务,以保持对内服务的稳定
common: utils enum constant
app:业务逻辑开发完成后,在这里打包,发布
test:写单元测试和非正式代码,后续会要求代码覆盖率
命名规范
app: 只有启动类Application
test: 除集成类测试,单元测试类命名=原始类+Test后缀
web: 后缀controller
biz: 后缀Manager
core: 后缀service
dal: 后缀Mapper,实体类DO和数据库表一一对应
facade: 后缀facade
integration : 后缀client
model: DTO数据传输性质如序列化 BO业务封装对象最常见 VO面向显示层的属性输出
util: 后缀utils
enum: 后缀enum
constant: Property等,不做强制约束,做到见名知意
exception: 后缀Exception Error
开发规范
业务逻辑只发生在biz层和core层,禁止在其他层里面出现任何业务逻辑
各模块内保持单一职责,按照业务或职责划分package
禁止在业务中直接引用外部服务,必须在integration中处理成client,并处理异常情况
禁止core依赖biz层,web依赖dal层
禁止更改各个model的原始依赖顺序,如发现无法引用,请考虑依赖的合理性
请保持dal层sql或指令的简洁性,不推荐写复杂sql或在sql中实现业务逻辑,要短平快
统一在父pom里面处理依赖
常量类使用接口或者枚举
日志规范
日志分级,error/other,分别输出到不同文件
禁止error到处飞,线上新增error日志必须高度敏感,做好监控
系统的入口和出口,以及关键位置必须有日志输出,不要怕日志打的多
线上禁止输出debug
输出日志需带trace信息
异常规范
内部异常类统一继承自UnimapException,对可感知业务异常进行封装
异常根据严重程度分级 ERROR WARNING,其中ERROR会拦截输出到error日志中
对外异常进行分类,定义错误码体系
建议将受检异常转为非受检异常
Git规范
主分支 master 主分支的合并应该在预发通过后,禁止直接提交master
功能分支 feature-*-#version 开发分支，在开发阶段使用,禁止提交不可编译运行的代码
发布版本 release-*-#version 测试和预发分支,提交QA的相对稳定版本
紧急修复分支 bugfix-*-#version 紧急修复线上bug
如无明确的版本计划,version建议为上线的日期
编码为utf8,换行符为\r LF,禁止Tab
URL规范
全部小写,单词间用-中划线分割
读请求为get,写请求为post
对外进行Response统一封装
建议rest风格,参数小于等于3个