1.【强制】存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。

说明：有缺陷的底层数据结构容易导致系统风险上升，可扩展性下降，重构成本也会因历史数据迁移和系统平滑过渡而陡然增加，所以，存储方案和数据结构需要认真地进行设计和评审，生产环境提交执行后，需要进行 double check。

正例：评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等；数据结构变更（如在原有表中新增字段）也需要在评审通过后上线。

2.【强制】在需求分析阶段，如果与系统交互的 User 超过一类并且相关的 UseCase 超过 5 个，使用用例图来表达更加清晰的结构化需求。

用户类

1. POJO（Plain Ordinary Java Object）：在本规约中，POJO 专指只有 setter / getter / toString 的简单类，包括DO / DTO / BO / VO 等。

2. DO（Data Object）：阿里巴巴专指数据库表一 一对应的 POJO 类。此对象与数据库表结构一 一对应，通过 DAO 层向上传输数据源对象。

3. PO（Persistent Object）：也指数据库表一 一对应的 POJO 类。此对象与数据库表结构一 一对应，通过 DAO 层向上传输数据源对象。

4. DTO（Data Transfer Object ）：数据传输对象，Service 或 Manager 向外传输的对象。

(一) 应用分层

1.【推荐】根据业务架构实践，结合业界分层规范与流行技术框架分析，推荐分层结构如图所示，默认上层依赖于下层，箭头关系表示可直接依赖，如：开放 API 层可以依赖于 Web 层（Controller 层），也可以直接依赖于 Service 层，依此类推：

• ⚫ 开放 API 层：可直接封装 Service 接口暴露成 RPC 接口；通过 Web 封装成 http 接口；网关控制层等。

• ⚫ 终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。

• ⚫ Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

• ⚫ Service 层：相对具体的业务逻辑服务层。

• ⚫ Manager 层：通用业务处理层，它有如下特征

• 1）对第三方平台封装的层，预处理返回结果及转化异常信息，适配上层接口。

• 2）对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。

• 3）与 DAO 层交互，对多个 DAO 的组合复用。

• ⚫ DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase、OceanBase等进行数据交互。

• ⚫ 第三方服务：包括其它部门 RPC 服务接口，基础平台，其它公司的 HTTP 接口，如淘宝开放平台、支付宝付款服务、 高德地图服务等。

• ⚫ 外部数据接口：外部（应用）数据存储服务提供的接口，多见于数据迁移场景中。

(一) 建表规约

1.【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（1 表示是，0 表示否）。

注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在设置从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。

• 说明：任何字段如果为非负数，必须是 unsigned。
• 正例：表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。

1.【强制】好的单元测试必须遵守 AIR 原则。

说明：单元测试在线上运行时，感觉像空气（AIR）一样感觉不到，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。

• ⚫ A：Automatic（自动化）
• ⚫ I：Independent（独立性）
• ⚫ R：Repeatable（可重复）

2.【强制】单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。不允许使用 System.out 来进行人肉验证，单元测试必须使用 assert 来验证。

(一) 命名风格

1.【强制】所有编程相关的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。

反例：_name / __name / $Object / name_ / name$ / Object$

(一)、错误码

1.【强制】错误码的制定原则：快速溯源、沟通标准化。

说明：错误码想得过于完美和复杂，就像康熙字典的生僻字一样，用词似乎精准，但是字典不容易随身携带且简单易懂。

正例：错误码回答的问题是谁的错？错在哪？

• 1）错误码必须能够快速知晓错误来源，可快速判断是谁的问题。
• 2）错误码必须能够进行清晰地比对（代码中容易 equals）。
• 3）错误码有利于团队快速对错误原因达到一致认知。

2.【强制】错误码不体现版本号和错误等级信息。

1.【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。

说明：防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容。

2.【强制】用户敏感数据禁止直接展示，必须对展示数据进行脱敏。

正例：中国大陆个人手机号码显示：139****1219，隐藏中间 4 位，防止隐私泄露。

3.【强制】用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 访问数据库。

反例：某系统签名大量被恶意修改，即是因为对于危险字符#--没有进行转义，导致数据库更新时，where 后边的信息被注释掉，对全库进行更新。