前言
在我们平时的开发中，可能分配到手上就是一个简单的需求，公司不一定有充足的实例给每一个需求新建工程，导致我们总是停留在业务代码层面，无法从一个项目的底层技术去了解一个项目。今天这节课，我们学习了怎么从零搭建一个项目，怎么设计项目结构。
作业回顾
用例图核心：用户行为
类图核心：
- 模型的抽象
- 模型之间的关系
时序图核心：
- 对象之间协作
- 随着时间推动，做了什么
状态图核心：
- 关注多少个状态
- 触发系统状态变化的条件
活动图：
- 多少个系统，参与了协作
- 每个处理流程的瞬间判断，循环
应用分层
隐藏下层业务逻辑的复杂性
提高系统的组件化和可维护性
为什么要分层？
以一个餐厅为例
如果你只有自己一个人，那么所有的工作都要由你来做，点餐 + 制作 + 上菜；当你的客户多起来后，你发现你顾不上揽客、顾不上点餐、还要烧菜，你发现你忙不过来了
怎么办？把工作流程分开，不同的人做不同的事
- 服务员负责揽客
- 下单员负责下单
- 厨师负责烧菜
当客户多了之后，如果揽客缺人手，那就招服务员，下单缺人手，那就招下单员，厨师缺就招厨师，每个角色都自己负责的部分。
MVC架构
- View：视图；jsp、html页面
- Controller：控制器；将用户请求分发给不同的Model处理，并向客户返回处理结果
- Model：Dao + Service；承载数据，并对客户的请求进行业务逻辑处理。
View => 服务员
Controller => 控制器
Model => 厨师
应用跟餐厅一样，分层就是为了让专门的模块做专门的事
- 可扩展性
- 可维护性
（计算机领域的任何问题都可以通过增加一个中间层解决）
推荐分层结构
分层异常处理
- DAO：这一层主要职责就是数据库持久化，异常都是MySQL的非运行时异常，不需要处理
- Manager/Service：必须记录错误日志，尽可能带上参数，保护案发现场；如果是调三方服务（非这个工程的都算三方服务）的接口，一定要在出入参加日志，方便定位问题
- Web：这一层直接与客户交互，绝不能往上抛异常，应跳转到友好错误页面， 友好的错误提示信息
- 开放接口层：将异常处理成错误码和错误信息返回，建议加上出入参日志
Maven
- 管理项目中的依赖关系
- 对项目进行构建
Maven是什么？
主流的构建工具
Maven主要功能：
- 依赖管理
- 规范目录结构
- 完整的项目构建阶段
- 支持多种插件
Maven的依赖仲裁
- 按照DependencyManager版本声明进行仲裁。
- 如无仲裁声明，则按照依赖最短路径确定版本。
- 若相同路径，则按照第一声明优先原则。
查找依赖冲突
- 企业版idea ：Show Dependencies
- 使用插件maven helper
依赖解决冲突
exclusion 排除依赖
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.10.0</version>
<exclusions>
<exclusion>
<artifactId>log4j-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
</exclusion>
</exclusions>
</dependency>option 可选依赖
当option 为 true 时，将不会接收到依赖传递
<dependency>
<groupId>sample.ProjectD</groupId>
<artifactId>ProjectD</artifactId>
<version>1.0-SNAPSHOT</version>
<optional>true</optional>
</dependency>
二方库
- 定义GAV（GroupID、ArtifactID、Version）规则及版本号规则
- 定义二方库发布及引用规则
一方库：
本工程中的各个模块相互依赖
二方库：
公司内部的依赖库，一般指公司内部的其他项目发布的jar包
三方库：
公司之外的开源库
二方库 GAV命名规范
GroupID
- 格式：com.{公司/BU }.业务线 [.子业务线]，最多 4 级。
- 说明：{公司/BU} 例如： alibaba/taobao/tmall/aliexpress 等 BU 一级； 子业务线可选。
- 正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
ArtifactID
- 格式：产品线名-模块名。语义不重复不遗漏，先 到中央仓库去查证一下。
- 正例：dubbo-client / fastjson-api / jstorm-tool
Version
- 主版本号：产品方向改变，或者 大规模 API 不兼容， 或者架构不兼容升级
- 次版本号：保持相对兼容性，增加主要 功能特性，影响范围极小的 API 不兼容修改。
- 修订号：保持完全兼容性，修 复 BUG、新增次要功 能特性等。
说明：注意起始版本号必须为：1.0.0，而不是 0.0.1。 反例：仓库内某二方库版本号从 1.0.0.0 开始，一直默默“升级”成 1.0.0.64，完全失去版本的语义信息。
二方库引用规约
- 线上应用不要依赖SNAPSHOT
- 正式发布的类库必须去中央库查证，使用RELEASE版本号有延续性
- 正式发布的类库版本号不允许覆盖升级
- 二方库的新增和升级，除了保持功能点之外的其他jar包仲裁结果不变
- 二方库定里定义的枚举类型，参数中可以使用返回值不允许使用
- 依赖一个二方库群时，必须定义一个统一的版本变量，避免版本不一致
- 禁止在依赖中出现相同的groupId ，相同的ArtifactId，但是不同的version
二方库引用建议
- 底层基础技术框架、核心数据管理平台、或接近硬件端系统谨慎引入第三方实现
- 所有版本仲裁使用<dependencyManagement>语句快
- 二方库不要有配置项
- 不要使用不稳定的工具包或工具类
二方库发布原则
精准可控原则
- 移除不必要的api 和 依赖
- 只包含Service API、以及没必要的工具类
- 如果依赖二方库，尽量provided 引入
- 无 log 具体实现，只依赖日志框架
稳定可追溯原则
- 记录每个版本的变化
- 二方库维护者
- 源码的位置
- 公共二方库行为不变
参考文档：无尘老师ppt
锲而舍之，朽木不折；锲而不舍，金石可镂。 ——荀子《劝学》