此文为阅读阿里巴巴Java开发手册时，将个人认为重要或值得注意的规范记作学习笔记。此为第六、七章——工程结构及设计归约。
工程结构
应用分层(No.1）
图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于
Web 层，也可以直接依赖于 Service 层，依此类推：
- 开放接口层： 可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。
- 终端显示层： 各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。
- Web 层： 主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
- Service 层： 相对具体的业务逻辑服务层。
- Manager 层： 通用业务处理层，它有如下特征：
1） 对第三方平台封装的层，预处理返回结果及转化异常信息；
2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；
3） 与 DAO 层交互，对多个 DAO 的组合复用。 - DAO 层： 数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
- 外部接口或第三方平台： 包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。
二方库依赖(No.4）
二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变，必须明确评估和验证，建议进行 dependency:resolve 前后信息比对，如果仲裁结果完全不一致，那么通过 dependency:tree 命令，找出差异点，进行<excludes>排除 jar 包。
二方库依赖(No.7）
禁止在子项目的 pom 依赖中出现相同的 GroupId，相同的 ArtifactId，但是不同的Version。
说明：在本地调试时会使用各子项目指定的版本号，但是合并成一个 war，只能有一个版本号出现在最后的 lib 目录中。可能出现线下调试是正确的，发布到线上却出故障的问题。
二方库依赖(No.10）
为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则：
- 精简可控原则。 移除一切不必要的 API 和依赖，只包含 Service API、必要的领域模型对象、Utils 类、常量、枚举等。如果依赖其它二方库，尽量是
provided引入，让二方库使用者去依赖具体版本号；无 log 具体实现，只依赖日志框架。 - 稳定可追溯原则。 每个版本的变化应该被记录，二方库由谁维护，源码在哪里，都需要能方便查到。除非用户主动升级版本，否则公共二方库的行为不应该发生变化。
服务器 (No.1）
高并发服务器建议调小 TCP 协议的 time_wait 超时时间。
说明：操作系统默认 240 秒后，才会关闭处于 time_wait 状态的连接，在高并发访问下，服务器端会因为处于 time_wait 的连接数太多，可能无法建立新的连接，所以需要在服务器上调小此等待值。
正例：在 linux 服务器上请通过变更/etc/sysctl.conf 文件去修改该缺省值（秒）：net.ipv4.tcp_fin_timeout = 30
服务器 (No.3）
给 JVM 环境参数设置-XX:+HeapDumpOnOutOfMemoryError 参数，让 JVM 碰到 OOM 场景时输出 dump 信息。
说明：OOM 的发生是有概率的，甚至相隔数月才出现一例，出错时的堆内信息对解决问题非常
有帮助。
服务器 (No.5）
服务器内部重定向使用 forward；外部重定向地址使用 URL 拼装工具类来生成，否则会带来 URL 维护不一致的问题和潜在的安全风险
设计归约
UML设计场景(No.2~6）
-
在需求分析阶段，如果与系统交互的 User 超过一类并且相关的 User Case 超过 5 个，使用用例图来表达更加清晰的结构化需求。
-
如果某个业务对象的状态超过 3 个，使用状态图来表达并且明确状态变化的各个触发条件。
说明：状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换关系，再明确触发状态转换的条件是什么。
正例：淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两种状态之间是不可能有直接转换关系的。 -
如果系统中某个功能的调用链路上的涉及对象超过 3 个，使用时序图来表达并且明确
各调用环节的输入与输出。
说明：时序图反映了一系列对象间的交互与协作关系，清晰立体地反映系统的调用纵深链路。 -
如果系统中模型类超过 5 个，并且存在复杂的依赖关系，使用类图来表达并且明确类之间的关系。
说明：类图像建筑领域的施工图，如果搭平房，可能不需要，但如果建造蚂蚁 Z 空间大楼，肯定需要详细的施工图。 -
如果系统中超过 2 个对象之间存在协作关系，并且需要表示复杂的处理流程，使用活动图来表示。
说明：活动图是流程图的扩展，增加了能够体现协作关系的对象泳道，支持表示并发等。
异常流程与业务边界(No.7）
需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。
反例：用户在淘宝付款过程中，银行扣款成功，发送给用户扣款成功短信，但是支付宝入款时由于断网演练产生异常，淘宝订单页面依然显示未付款，导致用户投诉。
系统架构设计的目的(No.16）
系统架构设计的目的：
- 确定系统边界。 确定系统在技术层面上的做与不做。
- 确定系统内模块之间的关系。 确定模块之间的依赖关系及模块的宏观输入与输出。
- 确定指导后续设计与演化的原则。 使后续的子系统或模块设计在规定的框架内继续演化。
- 确定非功能性需求。 非功能性需求是指安全性、可用性、可扩展性等。
水平权限控制
『水平权限管理问题』，又可以称之为『基于数据的访问控制』：相比垂直权限管理来说，水平权限问题出现在同一个角色上，系统只验证了能访问数据的角色，没有对数据的子集做细分，因此缺乏了一个用户到数据级之间的对应关系。对于数据的访问控制，与业务结合的比较紧密，目前还没有统一的数据级权限管理框架，一般是具体问题具体解决。
资料来源：
1.阿里巴巴Java开发手册(1.4.0)
2.权限控制的解决方式