1. 应用分层
1.1 为什么要分层？
- 隐藏下层业务逻辑的复杂性
- 提高系统的组件化和可维护性 可扩展性、可维护性 计算机领域的任何问题都可以通过增加一个中间层解决
1.2 MVC框架模式
Model 数据以及数据的处理
1.3 推荐分层结构
1.4 分层异常处理
1.5 分层领域模型
- DO（Data Object）此对象与数据库表结构一一对应，通过DAO层向上传输数据源对象
- DTO（Data Transfer Object）数据传输对象，Service或Manager向外传输的对象
- BO(Business Object) 业务对象，可以由Service层输出的封装业务逻辑的对象
- Query 数据查询对象，各层接受上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输
- VO(View Object) 显示层对象，通常是Web向模版渲染引擎层传输的对象
2. Maven
2.1 什么叫做构建
2.2 Java项目构建工具
- 传统工具 Ant
- 主流构建工具 Maven
- 新兴构建工具 Gradle
2.3 Maven的主要功能
- 依赖管理
- 规范目录结构
- 完整的项目构建阶段
- 支持多种插件
2.4 Maven的依赖仲裁
- 按照DependencyManager版本声明进行仲裁
- 如无仲裁声明，则按照依赖最短路径确定版本
- 若相同路径，则按照第一声明优先原则
2.5 Maven依赖排除
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
3. 二方库
3.1 什么是二方库
- 一方库 本工程中的各模块的相互依赖
- 二方库 公司内部的依赖库，一般指公司内部的其他项目发布的jar包
- 三方库 公司之外的开源库，比如apache、alibaba、google等
3.2 二方库GroupID、ArtifactID定义
1.GroupID
格式：com.{公司/BU}.业务线{.子业务线}，最多4级
正例 com.taobao.jstorm 或者com.alibaba.dubbo.register
2. ArtifactID
格式：产品线名-模块名。语义不重复不遗漏，先到中央仓库去查证一下
正例 dubbo-client /fastjson-api /jstorm-tool
3.3 二方库中Version的命名方式
二方库版本号命名方式：主版本号.次版本号.修订号
3.4 二方库引用规约
- 线上应用不要依赖sNAPSHOT版本
- 正式发布的类库必须去中央仓库查证，使RELEASE版本号有延续性
- 正式发布的类库版本号不允许覆盖升级
- 二方库的新增或升级，保证除功能点之外的其他jar包仲裁结果不变
- 二方库里定义的枚举类型，参数中可以使用，返回值不允许使用
- 依赖一个二方库群时，必须定义一个统一的版本变量，避免版本号不一致
- 禁止在依赖中出现相同的GroupId，相同的ArtifactId，但是不同的Version
3.5 二方库引用建议
- 底层基础技术框架、核心数据管理平台、或近硬件端系统谨慎引入第三方实现
- 所有版本仲裁使用
<dependencyManagement>语句块 - 二方库不要有配置项
- 不要使用不稳定的工具包或者Utils类
3.6 二方库发布原则
4. TCP/IP
4.1 TCP/IP的五层结构
4.2 IP协议的报头
4.3 TCP协议的报头
4.4 TCP的三次握手
4.4.1 为什么需要三次握手？
- 信息对等
- 防止超时
4.4.2 回答好三次握手
4.5 TCP的四次挥手断开连接
4.6 高并发服务器参数调优
补充
问题：各个图都是在什么阶段用？
1. 用例图 需求分析阶段
2. 状态图 设计阶段
3. 类图 开发前
4. 时序图 开发前、开发中
5. 活动图 需求分析后期
