Falsework架构和规范设计

发表于 | 分类于
| 字数统计 815 | 阅读时长 4

需求规划

  实现OAuth 2.0服务端和客户端，实现用户角色控制，Token权限控制和授权数据统计；围绕这个需求，将项目架构从单体架构，到分层架构，再到微服务架构的演变。

架构设计

架构图

Falsework架构图

架构设计

Controller（访问控制转发层）

  1. 校验token；
  2. 用户权限校验；
  3. 用户角色校验；
  4. 参数校验；
  5. 数据校验；
  6. 数据序列化；
  7. 轻业务逻辑；
  8. 异常兜底；
  9. 建议每一个Controller方法都得对应一个Service

Service（业务逻辑服务层）

  1. 复杂的业务编排逻辑处理；
  2. 捕捉异常；
  3. 复用性低；
  4. 使用DTO<VO>作为领域模型；
  5. Service层不能和Manager层相互调用；

Mannager（通用业务处理层）

  1. 对第三方平台封装的层，预处理返回结果及转化异常信息；
  2. 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；
  3. 与 DAO 层交互，对多个 DAO 的组合复用；
  4. 复用性高；
  5. 可以是单个服务，也可以是复合服务，比如多表查询；
  6. 使用DTO<VO>作为领域模型；
  7. Service层不能和Manager层相互调用；

DAO（数据持久访问层）

  1. 将对象与表结构简历ORM映射关系；
  2. Redis缓存操作；
  3. Cache缓存操作；
  4. 只允许对应的Service访问；
  5. 使用DO作为领域模型；

架构原则

  1. 前后端分离架构
  2. Web/App(Android/iOS)/Open(对外开放OAuth)共用一套接口；
  3. 使用JSON作为交互协议；
  4. 使用Swagger作为接口文档；
  5. 使用HATEOAS构建RESTful Web API JSON;
  6. RESTful API命名使用名词复数；

规范设计

表结构规范

  1. 数据库表的命名t_为开头；
  2. 表的主键有两个，表序号id，分布式的全球唯一标识only_id；
  3. 字段命名下划线规则，无大写，下划线分离开单词。

请求规范

  1. 创建使用post请求；
  2. 删除使用delete请求；
  3. 更新使用put请求；
  4. 查询使用get请求；

入参规范

  1. 使用application/x-www-form-urlencoded与application/json;charset=UTF-8并存。
  2. 使用Token身份认证，解决判断和权限鉴定，采用AOP面向切面编程认证Token;

出参规范

  1. 使用application/json;charset=UTF-8
  2. data使用List<T>;
  3. code使用int;
  4. msg使用String;
  5. 使用标准的HTTP Status Code；
  6. List中包含分布式全球唯一标识；

参数校验规范

争议

防御派

方法应该为自己负责，我不能保证调用者是否进行了校验，所以我必须要进行校验，从而保证程序的健壮性。

简约派

方法应该校验，但是不应该重复校验。重复校验产生了冗余的代码，导致程序可读性差。

标准

开发自用方法

权限：private,protected ,default

参数是可控的，在方法中不必校验参数合法性，调用者在调用之前应确认传入参数的合法性。

开发公共方法

权限：public

参数是不可控的，在方法中必须校验参数的合法性，因为无法保证调用者的行为和传入参数的合法性。

参考文档

你的项目应该如何正确分层？