工程结构规约

一、应用分层

隐藏下层业务逻辑的复杂性

提高系统的组件化和可维护性

MVC框架模式：Model View Controller

推荐分层结构：

分层异常处理：

DAO层 → 异常类型很多，不需要打印日志

Manager/Service层 → 必须记录出错日志到磁盘，尽量带上参数信息，保护案发现场

Web层 → 绝不能往上抛异常，应跳转到友好错误页面，友好的错误提示信息

开放接口层 → 将异常处理成错误码和错误信息方式返回

分层领域模型：

DO(date object) 此对象与数据库表结构一一对应，通过DAO层向上传输数据源对象

DTO  数据传输对象，Service或Manager向外传输的对象

BO(business object)  业务对象，可以由Service层输出的封装业务逻辑的对象

Query 数据查询对象，各层接收上层的查询请求；注意超过2个参数的查询封装，禁止使用Map类传输

VO(view object)  显示层对象，通常是web向模板渲染引擎层传输的对象

二、Maven

管理项目中的依赖关系

对项目进行构建

主要功能：依赖管理/规范目录结构/完整项目构建阶段/支持多种插件

GAV（工程坐标） G：groupId   A：artifactId   V：version

Maven的依赖仲裁：

1. 按照DependencyManager版本声明进行仲裁
2. 如无仲裁声明，则按照依赖最短路径确定版本
3. 若相同路径，则按照第一声明优先原则

三、二方库依赖

GroupID、ArtifactID的定义

GroupID栗子 com.taobao.jstorm或com.alibaba.dubbo.register

ArtifactID栗子 dubbo-client/fastjson-api/jstorm-tool

二方库引用规约：

1. 线上应用不要依赖SNAPSHOT版本
2. 正式发布的类库必须去中央仓库查证，使RELEASE版本号由延续性
3. 正式发布的类库版本号不允许覆盖升级
4. 二方库的新增或升级，保持除功能点之外的其他jar包仲裁结果不变
5. 二方库里定义的枚举类型，参数中可以使用返回值不允许使用
6. 依赖于一个二方库群时，必须定义一个统一的版本变量，避免版本号不一致
7. 禁止在依赖中出现相同的GroupId，相同的ArtifactId，但是不同的Version

二方库发布原则：

精简可控（移除不必要API和依赖；只包含ServiceAPI以及必要的工具类；如依赖其它二方库，尽量provided引入；无log具体实现，只依赖日志框架）

稳定可追溯（记录每个版本的变化；二方库维护者；源码的位置；公共二方库行为不变）