应用分层：
工程结构是一开始最纠结的地方，关于service层能够干什么，层与层之间用什么DO/PO/DTO，都是很伤脑筋的问题。
状态图：关注状态有多少，状态切换触发的条件是什么
- 用例图关注：1）用户角色有哪些。2）用户可以做哪些事情。
- 用例图是需求分析阶段的
- 活动图是需求分析后期的。
- 状态是设计阶段的。
- 类图是开发前的
- 时序图是开发前的，也可以开发中。
MVC——解耦
- model：模型、数据。对页面支撑的数据、对数据进行处理的业务逻辑。Service、Dao、pojo类。类比为厨师
- controller：全盘统筹。类比为服务员
- view：Jsp、模板、创作页面。类比为顾客
表现层：app、windows客户端、页面、一个对外开放供其它客户端调用的api。
通用逻辑层：专门抽取出来的共用、特殊的service层
dao层：使用mybatis框架。
第三方服务：也用于访问数据，若调用第三方数据，额外有防火层，得将数据、状态码转换为自己的数据格式和状态码（严禁引入第三方状态码）。
关于分层异常处理
- DAO层：异常类型较多，无需打印日志。
- Service或Manager层：需记录出错的日志到磁盘，尽可能带上参数信息，以保护案发现场。
- Web层：不能向上抛异常给客户，应跳转到友好错误界面、进行友好的错误信息提示。
- 开放接口层：将异常处理成错误码和以错误信息方式返回。
分层的领域模型：
- DO（Data Object）：对象与数据库表结构一一对应，通过DAO层向上传输数据源对象，是业务逻辑对象，可暴露所有字段，是内部使用，controller层调用service层。例如自己写的select所返回的查询结果；如果查询时多表连接查询出的结果，也属于DO范畴和po基本是一个道理。
- DTO（Data Transfer Object）：数据传输对象，Service或Manager层向外传输的对象，设计数据传输（服务器交换数据时，用到的部分数据放入DTO里），包括对象的序列化和反序列化，而BO中不涉及。DTO可用来接控制层参数。
- BO（Business Object）：非常强的业务属性概念。实质是业务对象，可以由Service层输出的封装业务逻辑的对象。
- Query：可简单看做接口的入参。数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。
- VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
- ——得能做到区分DO和VO，其余视情况而定，BO用的不多。
构建-Build
- 传统：批处理。
- 现在：构建工具，如传统Ant（打包，不能管理依赖）、主流Maven、新型Gradle。
GAV：工程的座标
- G：groupId
- A：artifactid
- V：version
关于确定jar，不同版本号依赖的是哪一个——声明仲裁。
- 按照DependencyManager版本声明进行仲裁。
- 如果没有仲裁声明，则按照依赖最短路径确定版本。
- 如果是相同的路径，按照第一声明优先原则。
版本、二方库规约等
命名方式：主版本号.次版本号.修订号
- 主版本号：产品方向改变或者大规模API不兼容或者产品架构不兼容升级。
- 次版本号：保持相对兼容性，增加主要功能特性，影响范围极小的API不兼容修改。
- 修订号：保持完全兼容性，修复BUG，新增次要功能特性等。
说明：注意起始版本号必须为：1.0.0，而不是0.0.1。
反例：仓库内某二方库版本号从1.0.0.0开始，一直依次默默升级为1.0.0.64，将完全失去版本的语义信息。
一些其他二方库引用规约
线上应用不要依赖SNAPSHOT版本
正式发布的类库必须去中央仓库查证，使RELEASE版本号有延续性
正式发布的类库版本号不允许覆盖升级
二方库的新增或升级，保持除功能点之外的其它jar包仲裁结果不变，即保证升级时使用maven中的resolve命令功能。
二方库里定义的枚举类型，参数中可以使用
日志设计文档：
错误码设计文档：
异常处理设计文档：