孤尽训练营打卡日记day08项目搭建规范

前言

        在我们平时的开发中，可能分配到手上就是一个简单的需求，公司不一定有充足的实例给每一个需求新建工程，导致我们总是停留在业务代码层面，无法从一个项目的底层技术去了解一个项目。今天这节课，我们学习了怎么从零搭建一个项目，怎么设计项目结构。

作业回顾

用例图核心：用户行为

类图核心：

• 模型的抽象
• 模型之间的关系

时序图核心：

• 对象之间协作
• 随着时间推动，做了什么

状态图核心：

• 关注多少个状态
• 触发系统状态变化的条件

活动图：

• 多少个系统，参与了协作
• 每个处理流程的瞬间判断，循环

应用分层

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

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

为什么要分层？

以一个餐厅为例

        如果你只有自己一个人，那么所有的工作都要由你来做，点餐 + 制作 + 上菜；当你的客户多起来后，你发现你顾不上揽客、顾不上点餐、还要烧菜，你发现你忙不过来了

怎么办？把工作流程分开，不同的人做不同的事

• 服务员负责揽客
• 下单员负责下单
• 厨师负责烧菜

        当客户多了之后，如果揽客缺人手，那就招服务员，下单缺人手，那就招下单员，厨师缺就招厨师，每个角色都自己负责的部分。

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 排除依赖

org.apache.logging.log4jlog4j-core2.10.0log4j-apiorg.apache.logging.log4j


option 可选依赖

当option 为 true 时，将不会接收到依赖传递

sample.ProjectDProjectD1.0-SNAPSHOTtrue



二方库

• 定义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

二方库引用建议

• 底层基础技术框架、核心数据管理平台、或接近硬件端系统谨慎引入第三方实现
• 所有版本仲裁使用语句快
• 二方库不要有配置项
• 不要使用不稳定的工具包或工具类

二方库发布原则

精准可控原则

• 移除不必要的api 和 依赖
• 只包含Service API、以及没必要的工具类
• 如果依赖二方库，尽量provided 引入
• 无 log 具体实现，只依赖日志框架

稳定可追溯原则

• 记录每个版本的变化
• 二方库维护者
• 源码的位置
• 公共二方库行为不变

参考文档：无尘老师ppt

锲而舍之，朽木不折；锲而不舍，金石可镂。         ——荀子《劝学》