项目开发规范

1. 分层思想

• Open API Layer
• • 可直接封装 Service 方法暴露成 RPC 接口
• • 通过 Web 封装成 RESTful HTTP 接口
• • 进行网关安全、流量控制等
• Terminal View Layer
• • 各个端的模板渲染并执行显示，JS、Freemarker、JSP渲染，PC端、移动端展示等
• Request Logic Layer（Web Layer）
• • 访问控制转发
• • 基本参数校验
• • 不复用的业务简单处理等
• Business Logic Layer（Service Layer）
• • 具体的业务逻辑层
• Common Logic Layer（Manager Layer）
• • 通用的业务逻辑层
• • • 对 Service Layer 通用能力的下沉，如缓存、中间件等的通用处理
• • • 与 DAO Layer 交互对多个 DAO 的组合复用
• • • 对第三方平台封装层、预处理返回结果、及转化异常信息等
• Data Persistence Layer（DAO Layer）
• • 数据访问层，与底层 MySQL、Oracle、HBase 等进行数据交互
• External or Third Platform Interface
• • 包括其他服务的 RPC 开放接口，其他公司的 HTTP 接口等

2. 领域模型

• DO（Data Object）
• • 通过 DAO 层向上传输数据源的对象，与数据库表结构一一对应
• DTO（Data Transfer Object）
• • 数据传输对象，Manager 或 Service 向外传输的对象
• BO（Business Object）
• • 业务对象，封装了业务逻辑的对象
• VO（View Object）
• • 通常 Web Layer 向模板渲染引擎层的传输对象
• • 项目中的 Swagger Model 对应该 VO
• Query
• • 各层接收上层查询请求的数据查询对象
• • 推荐超过2个及以上的参数请封装成 Query 对象，不建议用 Map 类来传输

3. 异常处理

• DAO Layer 异常类型较多，无法用细粒度的异常 catch，使用 catch(Exception e) 方式并 throw new DAOException(e)，并推荐不需要打印日志，因为日志在 Manager/Service Layer 一定需要捕获并打印到日志中，避免重复打日志浪费性能和存储
• Service Layer 出现异常时必须记录出错信息并打印日志，尽可能带上参数信息以保护案发现场
• 若 Manager Layer 与 Service Layer 同机部署，日志方式与 DAO Layer 一致处理，若单机部署，则与 Service Layer 一致处理
• Web Layer 绝不应该继续往上抛出异常，若异常导致页面无法正常渲染，则直接跳转到友好错误页面并加上容易理解的错误提示信息
• Open API Layer 要将异常处理成错误码和错误信息的方式返回

4. UT/IT 实战：JUnit + TestNG + Unitils + Mockito + DbUnit + NinjaTest

来源