Java 编码规范

一、工程结构

1、应用分层

 

Client: 主要提供对外交互的API，各种Cmd或者Qry以及Response，并且遵循sofa的相关规范。

App层主要负责获取输入，组装context，做输入校验，发送消息给领域层做业务处理，监听确认消息，如果需要的话使用MetaQ进行消息通知；

Domain层主要是通过领域服务（Domain Service），领域对象（Domain Object）的交互，对上层提供业务逻辑的处理，然后调用下层Repository做持久化处理；

Infrastructure层主要包含Repository，Config和Common，Repository负责数据的CRUD操作，这里我们借用了盒马的数据通道（Tunnel）的概念，通过Tunnel的抽象概念来屏蔽具体的数据来源，来源可以是MySQL，NoSql，Search，甚至是HSF等；Config负责应用的配置；Common是一写工具类；负责message通信的也应该放在这一层

 

 

分层领域模型规约：

 DO（Data Object）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。

 DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。 一般来说对外提供的Command和Query都继承自DTO；

 BO（Business Object）：业务对象。由 Service 层输出的封装业务逻辑的对象。

 AO（Application Object）：应用对象。在 Web 层与 Service 层之间抽象的复用对象模型， 极为贴近展示层，复用度不高。

 VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。

 Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止 使用 Map 类来传输。

 

相应各层Java文件命名规范参见如下文件：

 

2、配置文件管理；

配置文件目录层次遵循maven的最佳实践：

代码块

Java

src

\-- main

|    \-- java

|    |-- resources

|        \-- spring  

|        |   \-- xxx-common-pigeon-client.xml

|        |   |-- xxx-common-mybatis.xml

|        |   |-- xxx-common-cache.xml

|        |   |-- xxx-pigeon-service.xml

|        |   |-- xxx-mvc-servlet.xml

|        |-- sqlmap

|        |   \-- dbName(db名称)

|        |       \-- ActivityInfoDOMapper.xml

|        |   |-- gmktacitivy

|        |-- log4j2.xml

|        |-- mybatis-generator.xml

|-- test

     \-- resources

 

3、项目依赖管理；

此处的依赖关系，主要管理提供给外部调用方的API、依赖第三方的外部API。需要说明的有以下几点

1）团队的所有maven构件的groupId定义要求以com.sankuai.web.trade(待定)为前缀，子业务通过artifactId来区分，不再在groupId后增加内容；

2) maven的version定义：{主版本号}.{次版本号}.{修订版本号}。

当增加了新的功能，或做了不兼容的改进时，一般需要更改主版本号；

当做了向下兼容的功能迭代（新增接口、类等）时，一般需要更改次版本号；

当保持API的方法签名不变，仅做了参数字段、枚举常量的增添，或者一些小的bug fix时，一般需要更改修订版本号；

说明：注意起始版本号必须为：1.0.0，而不是 0.0.1 正式发布的类库必须先去中央仓库进 行查证，使版本号有延续性，正式版本号不允许覆盖升级。如当前版本：1.3.3，那么下一个 合理的版本号：1.3.4 或 1.4.0 或 2.0.0

3) 线上应用不要依赖 SNAPSHOT 版本（安全包除外），内部的禁用，外部依赖请推动其发布正式包。

4) 在对外提供API的Jar时，建议仅包含API接口相关的声明类等，不要添加任何的第三方依赖，以防止给调用方带来一些不必要的传递依赖；对于API层的sofa依赖，请只依赖sofa-common；

5) 所有依赖的version声明应在父POM里面通过<dependencyManagement>来进行管理，而实际依赖的引入则在子POM的<dependencies>里面完成；
6) 公司基础组件请使用inf-bom，团队内部对于第三库的依赖请使用 trade-framework-bom；

 

4、服务器环境规范；

1）文献【3】详细定义了各个环境，以及北京、上海两地的环境对应关系，请参考。