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

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

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

GitHub地址:  https://github.com/mapcoding-cn/preferential-map

技术方面的简单介绍

在这个项目使用了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个

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注