一个地图小程序的后端项目

 很久没写文章了,做这个项目的目的-利用业余时间沉淀技术经验,准备一个好用的脚手架,同时尝试一些在工作中想用但是没机会用的技术

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个