[ADD]spring boot

docs/spring boot.md

@@ -2,39 +2,125 @@
 
 ### Spring Boot – 架构
 
-Spring Boot 层
-Spring Boot 由以下四层组成：
+Spring Boot应用的层次结构
 
-表示层 - 身份验证和json翻译
-业务层 - 业务逻辑、验证和授权
-Persistence Layer – 存储逻辑
-Database Layer – 实际数据库
+在Spring Boot项目中，典型的分层架构包括表现层（Presentation）、业务层（Business）、持久层（Persistence）和数据库层（Database）。合理划分各层职责，可以有效管理业务逻辑和数据访问，提高代码的清晰度和可测试性。
 
-图 1 – Spring Boot 的层
+![](./resources/imgs/spring-boot-layer.jpg)
 
-1. 表示层
+#### 表现层
 
-表示层是 Spring Boot 体系结构的顶层。它由 View 组成。即应用程序的前端部分。它处理 HTTP 请求并执行身份验证。它负责将 JSON 字段的参数转换为 Java 对象，反之亦然。一旦它执行了请求的身份验证，它就会将其传递到下一层。即业务层。
+表现层是Spring Boot架构的最顶层。它包含视图，即应用程序的前端部分。它处理HTTP请求并执行身份验证。负责将JSON字段参数转换为Java对象，反之亦然。一旦完成请求的身份验证，它就会将请求传递给下一层，即业务层。
 
-2. 业务层
+在前后端完全分离的情况下，Spring Boot的表现层的实现主要涉及如下内容：
 
-业务层包含所有业务逻辑。它由 services 类组成。它负责验证和授权。
+**RESTful API**：
+> 使用`@RestController`注解的控制器类来处理HTTP请求，返回JSON格式的数据。这些API通常用于与前端JavaScript框架（如React、Vue.js或Angular）交互。
 
-3. 持久层
+**跨域资源共享（CORS）**：
+> 为了支持前端应用从不同的域名发送请求，需要在Spring Boot应用中配置CORS。可以通过在控制器方法上使用`@CrossOrigin`注解或者全局配置CORS来实现。
 
-持久层包含所有数据库存储逻辑。它负责将业务对象转换为数据库行，反之亦然。
+**身份验证和授权**：
+> 使用Spring Security来处理用户身份验证和授权。Spring Security提供了多种方式来保护RESTful API，包括基于表单的登录、JWT（JSON Web Tokens）、OAuth2等。
 
-4. 数据库层
+**异常处理**：
+> 使用`@ControllerAdvice`和`@ExceptionHandler`注解来全局处理异常，确保API返回统一的错误信息格式。
 
-数据库层包含所有数据库，如 MySql、MongoDB 等。此层可以包含多个数据库。它负责执行 CRUD 操作。
+**请求和响应拦截**：
+> 使用`HandlerInterceptor`或`Filter`来拦截请求和响应，可以用于日志记录、性能监控、请求校验等。
+
+**静态资源处理**：
+> Spring Boot默认支持静态资源的处理，可以将HTML、CSS、JavaScript等文件放在`src/main/resources/static`目录下，Spring Boot会自动配置好静态资源的访问路径。
+
+**模板引擎**：
+> 尽管在前后端分离的架构中不常用，但Spring Boot仍然支持模板引擎（如Thymeleaf、FreeMarker等），用于渲染HTML页面。
 
 
-解释：
+#### 业务层
 
-客户端发出 HTTP 请求（GET、PUT、POST 等）
-HTTP 请求被转发到 Controller。控制器映射请求。它处理句柄并调用服务器逻辑。
-业务逻辑在 Service 层执行。Spring Boot 对通过 Java Persistence Library （JPA） 映射到 spring boot 模型类的数据库数据执行所有 logic 。
-JSP 页作为控制器的 Response 返回。
+业务层包含所有的业务逻辑。在spring boot应用中，在Spring Boot应用中，业务层（也称为服务层或应用层）的实现主要涉及以下几个方面：
+
+**服务类（Service Classes）**：
+> 这些类包含实现业务逻辑的方法，它们通常作为领域模型（即实体层）和控制器（表现层）之间的中介。
+
+**业务逻辑封装**：
+> 业务层负责封装核心业务逻辑，确保业务规则的一致性和正确性，以及数据的完整性。
+
+**验证（Validation）**：
+> 业务层负责对输入数据进行验证，确保它们符合业务规则和约束。这通常通过使用JSR 303/JSR 380注解（如`@NotNull`、`@Size`、`@Valid`等）来实现。
+
+**授权（Authorization）**：
+> 在业务层中，可以进行更细粒度的授权检查，以确保用户只能访问他们被授权的资源或执行他们被授权的操作。
+
+**事务管理（Transaction Management）**：
+> 业务层常常涉及到数据库事务的管理，Spring Boot通过声明式事务管理（使用`@Transactional`注解）来简化事务的控制。
+
+**异常处理**：
+> 业务层需要处理业务逻辑中可能发生的异常，并将其转换为对用户更友好的错误信息或业务异常。
+
+**业务流程协调**：
+> 业务层负责协调多个业务操作的执行顺序，实现复杂的业务流程。
+
+**数据转换**：
+> 业务层可能需要将领域模型（Domain Models）转换为DTOs（Data Transfer Objects），以适配前端的数据需求。
+
+**集成外部服务**：
+> 业务层可以集成和调用外部服务或API，如支付网关、邮件服务、第三方数据接口等。
+
+**业务决策**：
+> 业务层包含业务决策逻辑，这些逻辑基于业务规则和策略来指导应用程序的行为。
+
+**缓存管理**：
+> 业务层可以负责缓存策略的实现，以提高应用程序的性能。
+
+**异步处理**：
+> 对于耗时的业务操作，业务层可以实现异步处理机制，如使用Spring的`@Async`注解。
+
+**消息队列**：
+> 业务层可以与消息队列（如RabbitMQ、Kafka）集成，以实现异步消息传递和处理。
+
+#### 持久层
+
+持久层包含所有的数据库存储逻辑。它负责将业务对象转换为数据库行，反之亦然。在Spring Boot应用中，持久层的实现主要涉及以下几个方面：
+
+**数据访问对象（DAO）**：
+> DAO负责与数据库进行交互，执行CRUD操作。通常使用`@Repository`注解来标记DAO类。
+
+**实体类**
+> 数据库实体类是持久层与数据库交互的桥梁。它们定义了数据库中的表和字段，并映射为Java对象。
+
+**ORM框架**：
+> Spring Boot支持多种ORM框架，如JPA、Hibernate、MyBatis等。这些框架可以帮助开发者更方便地进行对象关系映射。
+ 
+**数据转换**：
+> 持久层可能需要将实体对象转换为数据库行，反之亦然。ORM框架通常会自动处理这些转换，但有时也需要手动编写转换逻辑。
+
+**查询优化**：
+> 持久层需要关注查询性能，可以通过索引优化、查询缓存、批量操作等方式来提高查询效率。
+
+### 数据库层
+
+数据库层包含所有类型的数据库，如MySQL、MongoDB等。在Spring Boot应用中，数据库层的实现主要涉及以下几个方面：
+
+**数据库选择**：
+> 根据应用的需求选择合适的数据库，如关系型数据库（MySQL、PostgreSQL）或NoSQL数据库（MongoDB、Cassandra）。
+
+**数据模型设计**：
+> 设计合理的数据模型，包括表结构、索引、外键等，以满足业务需求并优化查询性能。
+
+**数据迁移**：
+> 使用Flyway或Liquibase等工具进行数据库迁移，确保数据库结构的一致性和版本控制。
+**备份和恢复**：
+> 定期备份数据库，确保数据的安全性。在发生故障时，可以快速恢复数据。
+ 
+#### 流程架构
+
+[](./resources/imgs/spring-boot-flow-architecture.jpg)
+
+- 客户端发出 HTTP 请求（GET、PUT、POST 等）
+- HTTP 请求被转发到 Controller。控制器映射请求。它处理句柄并调用服务器逻辑。
+- 业务逻辑在 Service 层执行。Spring Boot 对通过 Java Persistence Library （JPA） 映射到 spring boot 模型类的数据库数据执行所有 logic 。
+- 控制器返回 HTTP 响应(Json或HTML)。
 
 ### Spring Boot – 代码结构
 
@@ -78,9 +164,9 @@ com
 * 测试和重构很容易。
 * 功能可以单独发布。
 
-**结构2： 按层**
+**结构2：按逻辑层次**
 
-可以将项目划分为服务层、实体层、存储库层等层。
+可以将项目划分为控制器层（接口层）、服务层、存储库层等层。
 所有控制器都可以放置在 Services Package 下的 controllers Package 和 Services 中，所有实体都可以放置在 Domain 或 Model 等下。
 ```text
 com
@@ -106,9 +192,9 @@ com
 
 ```
 
-尽管上述结构看起来可行并且很容易按层定位类。与 Structure by Feature 相比，它几乎没有缺点。
+尽管上述结构看起来可行并且很容易按层定位类。与按功能划分相比，它几乎没有缺点。但也存在以下缺点：
 
-功能部件或模块不能单独发布。
-很难找到与某个功能相关的类。
-对某个特征进行代码重构是困难的，因为特征类位于每一层中。
-它会导致使用 Git 等进行协作的开发人员之间发生合并冲突。
+* 功能部件或模块不能单独发布。
+* 很难找到与某个功能相关的类。
+* 对某个特征进行代码重构是困难的，因为特征类位于每一层中。
+* 它会导致使用 Git 等进行协作的开发人员之间发生合并冲突。