create folders for backend docs

Author: ying.liu

backend/README.md

@@ -2,17 +2,25 @@
 
 这里是有关后端项目的代码规范。
 
-## 文档说明
+## 开发流程
 
-- [后端服务开发基本流程](./basic-service-developer-flow.md): 关于后端各个服务开发的基本流程
-- [如何处理异常](./how-to-handle-exception.md): 关于异常处理的方式
-- [java编码指南](./java-code-guideline.md): 关于java编码的规约
-- [java测试框架及方式](./java-service-test.md): 关于如何进行单元测试和集成测试
-- [发版流程](./release-guideline.md): 关于发版的规范流程
-- [微服务开发规约](./service-basic-rule.md): 微服务开发规约
-- [swagger使用规约](./swagger-usage-guideline.md): 关于如何使用swagger生成api文档已经api文档的风格
-- [后端如何写日志](./如何写日志.md): 关于后端记日志的详细说明
-- [Java命名规范](./Java命名规范.md): 关于后端Java代码的命名规范
-- [API设计规范](./API设计规范.md): 关于后端API的设计规范
-- [数据库设计规范-mysql](./数据库设计规范-mysql.md): 关于数据库设计的规范
-- [Java后台项目如何分层](./Java后台服务分层规范.md): 关于Java后台服务项目如何分层的一些标准
+- [后端服务开发基本流程](./process/basic-service-developer-flow.md): 关于后端各个服务开发的基本流程
+- [发版流程](./process/release-guideline.md): 关于发版的规范流程
+- [API 设计规范](./process/API设计规范.md): 关于后端 API 的设计规范
+- [swagger 使用规约](./process/swagger-usage-guideline.md): 关于如何使用 swagger 生成 api 文档已经 api 文档的风格.
+- [java 测试框架及方式](./java-service-test.md): 关于如何进行单元测试和集成测试
+- [微服务开发规约](./process/service-basic-rule.md): 微服务开发规约
+- [审核 PR](./process/how-to-review-pr.md).
+
+## 编码规范
+
+- [如何处理异常](./code/how-to-handle-exception.md): 关于异常处理的方式
+- [java 编码指南](./code/java-code-guideline.md): 关于 java 编码的规约
+- [后端如何写日志](./code/如何写日志.md): 关于后端记日志的详细说明
+- [Java 命名规范](./code/Java命名规范.md): 关于后端 Java 代码的命名规范
+- [Java 后台项目如何分层](./code/database/Java后台服务分层规范.md): 关于 Java 后台服务项目如何分层的一些标准
+
+## 数据库
+
+- [数据库设计规范-mysql](./database/数据库设计规范-mysql.md): 关于数据库设计的规范
+- [数据库事务与隔离级别](./database/数据库事务与隔离级别.md)

backend/Java后台服务分层规范.md renamed to backend/code/Java后台服务分层规范.md

@@ -1,4 +1,4 @@
-# Java后台服务分层规范
+# Java 后台服务分层规范
 
 ## 0. 分层概述
 
@@ -7,39 +7,39 @@
 
 ## 1. 分层示例：
 
-![分层示例](./resources/java_project_layer.png)
+![分层示例](../resources/java_project_layer.png)
 
 其中各层的引用关系从上到下依次为：  
-API层 -> Application层 -> DomainService -> Repository -> DomainModel
+API 层 -> Application 层 -> DomainService -> Repository -> DomainModel
 
 引用关系见下图
-![分层示例](./resources/java_layer_depencies.png)
+![分层示例](../resources/java_layer_depencies.png)
 
-## 2. API层
+## 2. API 层
 
-API层用来定义对外的接口，对应于SpringMVC的Controller。  
-在API层定义接口格式（比如Swagger的各种标记)，也可以进行参数验证（比如使用@Validated)。  
-在API层实现登录及权限验证。  
-API层应该是很薄的一层，仅仅是参数验证，然后转发到Application层。
+API 层用来定义对外的接口，对应于 SpringMVC 的 Controller。  
+在 API 层定义接口格式（比如 Swagger 的各种标记)，也可以进行参数验证（比如使用@Validated)。  
+在 API 层实现登录及权限验证。  
+API 层应该是很薄的一层，仅仅是参数验证，然后转发到 Application 层。
 
-## 3. 应用层(Application层)
+## 3. 应用层(Application 层)
 
 应用层的每个方法定义软件要完成的一项任务；  
 应用层不包含具体的业务逻辑处理，而是协调业务逻辑层的类来完成任务；  
-API返回代码应该在应用层进行定义。
+API 返回代码应该在应用层进行定义。
 
-## 4. 领域层(Domain层)
+## 4. 领域层(Domain 层)
 
 领域层负责表达业务逻辑，是整个系统的核心层。  
 领域层的类根据职责不同，又划分为以下几部分：DomainModel, DomainService, Repository, ServiceProxy, Bo。
 
 ### 4.1 领域模型(DomainModel)
 
-- 领域模型应该是充血模型, 对DomainModel状态的修改应通过调用DomainModel的方法进行。  
-- 领域模型参照DDD中的聚合，实体，值对象的概念进行划分，对DomainModel的任何修改都应该通过聚合根进行。
-- 领域模型的创建属于领域层的职责，应该在领域层添加相应的工厂类（对于简单的实体，也可以直接在类中定义一个静态的create方法）。
+- 领域模型应该是充血模型, 对 DomainModel 状态的修改应通过调用 DomainModel 的方法进行。
+- 领域模型参照 DDD 中的聚合，实体，值对象的概念进行划分，对 DomainModel 的任何修改都应该通过聚合根进行。
+- 领域模型的创建属于领域层的职责，应该在领域层添加相应的工厂类（对于简单的实体，也可以直接在类中定义一个静态的 create 方法）。
 - 领域模型中聚合根应该由自身来维护状态的完整性。
-- 领域模型不应该暴露在应用层之外，应该通过Bo(领域层的数据传输对象)来与领域层外部交互。
+- 领域模型不应该暴露在应用层之外，应该通过 Bo(领域层的数据传输对象)来与领域层外部交互。
 
 ### 4.2 领域服务(DomainService)
 
@@ -49,37 +49,38 @@ API返回代码应该在应用层进行定义。
 
 ### 4.3 仓储(Repository)
 
-仓储根据职责分成两类：修改和查询(create，update和delete都归类为修改)。  
-这两类仓储可以采用不同的实现方式，比如修改采用Spring data JPA(Hibernate)，而查询可以直接采用JdbcTemplate。
+仓储根据职责分成两类：修改和查询(create，update 和 delete 都归类为修改)。  
+这两类仓储可以采用不同的实现方式，比如修改采用 Spring data JPA(Hibernate)，而查询可以直接采用 JdbcTemplate。
 
 ### 4.4 外部服务代理(ServiceProxy)
 
-对外部服务的调用应封装在单独的类中。也可以封装出外部服务的接口，调用者只注入接口即可，外部服务的实现类在运行时由Spring注入。
+对外部服务的调用应封装在单独的类中。也可以封装出外部服务的接口，调用者只注入接口即可，外部服务的实现类在运行时由 Spring 注入。
 
 ### 4.5 Bo(领域层的数据传输对象)
 
-对于领域层操作所需要的参数，或者领域层返回外部的数据，应该定义Bo对象，以避免暴露领域模型到外部。  
-Bo对象只应该包含简单的数据字段和一些验证方法，也可以包含从领域模型到Bo对象的转换方法。
+对于领域层操作所需要的参数，或者领域层返回外部的数据，应该定义 Bo 对象，以避免暴露领域模型到外部。  
+Bo 对象只应该包含简单的数据字段和一些验证方法，也可以包含从领域模型到 Bo 对象的转换方法。
 
-## 5. 基础设施层(infrastructure层)
+## 5. 基础设施层(infrastructure 层)
 
 基础设施层包含一些通用逻辑，如系统配置，常量定义，日志处理，缓存等，以及一些第三方组件的封装。
 
-## 6. utility层
+## 6. utility 层
 
-utility层包含一些共用的辅助方法。
+utility 层包含一些共用的辅助方法。
 
 ## 7. 最佳实践
 
 - 对于比较复杂的项目，每个分层中可以根据模块再分成多个目录，以方便管理。
-- 事务应该在ApplicationService或DomainService中定义，具体位置根据情况决定。
+- 事务应该在 ApplicationService 或 DomainService 中定义，具体位置根据情况决定。
 - 事务范围应尽量短，事务中不应包括远程服务调用及消息收发操作。
 
 - 关于消息的发送应遵守以下约定：
-  - 消息发送应该封装成独立的类，类名类似于xxxMessageProducer, 类定义放在DomainService目录下。
-  - xxxMessageProducer类似DomainService，可以由其他的DomainService或ApplicationService调用。
+
+  - 消息发送应该封装成独立的类，类名类似于 xxxMessageProducer, 类定义放在 DomainService 目录下。
+  - xxxMessageProducer 类似 DomainService，可以由其他的 DomainService 或 ApplicationService 调用。
 
 - 关于消息接收应遵守以下约定：
-  - 消息接收的具体实现类应定义在最外层中，和Controller类似，并创建一个独立的目录，目录名为consumer，命名类似于xxxMessageConsumer;
-  - xxxMessageConsumer调用ApplicationService来完成实际处理。
-  - xxxMessageConsumer类似xxxController，都是由外部调用发起。
+  - 消息接收的具体实现类应定义在最外层中，和 Controller 类似，并创建一个独立的目录，目录名为 consumer，命名类似于 xxxMessageConsumer;
+  - xxxMessageConsumer 调用 ApplicationService 来完成实际处理。
+  - xxxMessageConsumer 类似 xxxController，都是由外部调用发起。

backend/Java命名规范.md renamed to backend/code/Java命名规范.md

@@ -0,0 +1,4 @@
+# 服务开发的基本规约
+
+- 每个服务，只专注于一个功能模块的开发.
+- 在服务之间发送请求的时候，需要带上本地的 traceId，并将其置于 Header 中： “TraceId”