任务2.5
This commit is contained in:
@@ -238,12 +238,16 @@
|
||||
|
||||
`plan_controller.go` 当前包含了大量的业务逻辑，这违反了控制器层应只负责请求处理和响应发送的原则。具体问题包括：
|
||||
|
||||
- **业务规则判断**：控制器中直接判断计划类型（如 `models.PlanTypeSystem`）、计划状态（如 `models.PlanStatusEnabled`）以及 `ContentType` 的自动判断。
|
||||
- **领域对象创建与转换**：控制器直接使用 `dto.NewPlanFromCreateRequest` 和 `dto.NewPlanFromUpdateRequest` 将请求 DTO 转换为 `models.Plan`，并在响应前将 `models.Plan` 转换为 `dto.PlanResponse`。
|
||||
- **直接调用仓库层**：控制器直接调用 `planRepo` 的 `CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`, `GetBasicPlanByID`, `UpdatePlanStatus`, `UpdateExecuteCount`, `StopPlanTransactionally` 等方法。
|
||||
- **协调领域服务**：控制器直接协调 `analysisPlanTaskManager` 的 `EnsureAnalysisTaskDefinition` 和 `CreateOrUpdateTrigger` 方法。
|
||||
- **错误处理**：控制器直接通过 `errors.Is(err, gorm.ErrRecordNotFound)` 判断仓库层错误，并根据错误类型返回不同的 HTTP 状态码。
|
||||
- **执行计数器重置**：在 `UpdatePlan` 和 `StartPlan` 中，控制器直接处理 `ExecuteCount` 的重置逻辑。
|
||||
- **业务规则判断**：控制器中直接判断计划类型（如 `models.PlanTypeSystem`）、计划状态（如 `models.PlanStatusEnabled`）以及
|
||||
`ContentType` 的自动判断。
|
||||
- **领域对象创建与转换**：控制器直接使用 `dto.NewPlanFromCreateRequest` 和 `dto.NewPlanFromUpdateRequest` 将请求 DTO 转换为
|
||||
`models.Plan`，并在响应前将 `models.Plan` 转换为 `dto.PlanResponse`。
|
||||
- **直接调用仓库层**：控制器直接调用 `planRepo` 的 `CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`,
|
||||
`GetBasicPlanByID`, `UpdatePlanStatus`, `UpdateExecuteCount`, `StopPlanTransactionally` 等方法。
|
||||
- **协调领域服务**：控制器直接协调 `analysisPlanTaskManager` 的 `EnsureAnalysisTaskDefinition` 和 `CreateOrUpdateTrigger`
|
||||
方法。
|
||||
- **错误处理**：控制器直接通过 `errors.Is(err, gorm.ErrRecordNotFound)` 判断仓库层错误，并根据错误类型返回不同的 HTTP 状态码。
|
||||
- **执行计数器重置**：在 `UpdatePlan` 和 `StartPlan` 中，控制器直接处理 `ExecuteCount` 的重置逻辑。
|
||||
|
||||
这种设计导致控制器层职责过重，业务逻辑分散，难以维护和测试。
|
||||
|
||||
@@ -251,60 +255,160 @@
|
||||
|
||||
#### Goals
|
||||
|
||||
- **创建应用服务层**：引入一个新的 `internal/app/service/plan_service.go` 来封装 `plan` 模块的所有业务逻辑。
|
||||
- **迁移业务逻辑**：将 `plan_controller.go` 中识别出的所有业务规则判断、领域对象创建与转换、对仓库层的直接调用、对 `analysisPlanTaskManager` 的协调以及错误处理逻辑，全部迁移到新的 `PlanService` 中。
|
||||
- **简化控制器**：使 `plan_controller.go` 只负责 HTTP 请求处理、参数绑定、调用新的 `PlanService` 方法，并处理服务层返回的 DTO。
|
||||
- **统一服务层接口**：`PlanService` 的方法将接收 DTO 作为输入，并返回 DTO 作为输出，实现服务层接口的标准化。
|
||||
- **创建应用服务层**：引入一个新的 `internal/app/service/plan_service.go` 来封装 `plan` 模块的所有业务逻辑。
|
||||
- **迁移业务逻辑**：将 `plan_controller.go` 中识别出的所有业务规则判断、领域对象创建与转换、对仓库层的直接调用、对
|
||||
`analysisPlanTaskManager` 的协调以及错误处理逻辑，全部迁移到新的 `PlanService` 中。
|
||||
- **简化控制器**：使 `plan_controller.go` 只负责 HTTP 请求处理、参数绑定、调用新的 `PlanService` 方法，并处理服务层返回的
|
||||
DTO。
|
||||
- **统一服务层接口**：`PlanService` 的方法将接收 DTO 作为输入，并返回 DTO 作为输出，实现服务层接口的标准化。
|
||||
|
||||
#### Non-Goals
|
||||
|
||||
- **不修改业务逻辑**：本次重构不涉及任何已有业务规则的变更。所有业务逻辑将原封不动地从控制器迁移到服务层。
|
||||
- **不改变 API 契约**：对外暴露的 API 接口、请求参数和响应结构对最终用户保持不变。
|
||||
- **不改变领域服务**：不对 `internal/domain/scheduler/analysis_plan_task_manager.go` 的接口和实现进行任何修改。
|
||||
- **不改变仓库层接口**：不对 `internal/infra/repository/plan_repository.go` 的接口进行任何修改。
|
||||
- **不修改业务逻辑**：本次重构不涉及任何已有业务规则的变更。所有业务逻辑将原封不动地从控制器迁移到服务层。
|
||||
- **不改变 API 契约**：对外暴露的 API 接口、请求参数和响应结构对最终用户保持不变。
|
||||
- **不改变领域服务**：不对 `internal/domain/scheduler/analysis_plan_task_manager.go` 的接口和实现进行任何修改。
|
||||
- **不改变仓库层接口**：不对 `internal/infra/repository/plan_repository.go` 的接口进行任何修改。
|
||||
|
||||
### Decisions
|
||||
|
||||
- **决策：引入新的应用服务 `PlanService`**
|
||||
- **理由**：这是解决控制器职责过重和分层不清问题的标准做法。`PlanService` 将作为应用层门面，协调 `PlanRepository` 和 `AnalysisPlanTaskManager`，并为控制器提供一个清晰、稳定的接口。
|
||||
- **结构**：`PlanService` 将依赖于 `PlanRepository` 和 `AnalysisPlanTaskManager`。
|
||||
- **决策：引入新的应用服务 `PlanService`**
|
||||
- **理由**：这是解决控制器职责过重和分层不清问题的标准做法。`PlanService` 将作为应用层门面，协调 `PlanRepository` 和
|
||||
`AnalysisPlanTaskManager`，并为控制器提供一个清晰、稳定的接口。
|
||||
- **结构**：`PlanService` 将依赖于 `PlanRepository` 和 `AnalysisPlanTaskManager`。
|
||||
|
||||
- **决策：`PlanService` 接口全面采用 DTO**
|
||||
- **具体实现**：接口方法将接收 `dto.CreatePlanRequest`, `dto.UpdatePlanRequest`, `dto.ListPlansQuery` 等请求 DTO，并返回 `*dto.PlanResponse`, `*dto.ListPlansResponse` 等响应 DTO。
|
||||
- **理由**：这与 `monitor`、`device` 和 `pig-farm` 模块的重构决策一致，可以确保应用服务层的接口统一、清晰，并与上层（控制器）和下层（领域/仓库）完全解耦。服务层内部将负责 `DTO` 到 `models` 的转换以及 `models` 到 `DTO` 的转换。
|
||||
- **决策：`PlanService` 接口全面采用 DTO**
|
||||
- **具体实现**：接口方法将接收 `dto.CreatePlanRequest`, `dto.UpdatePlanRequest`, `dto.ListPlansQuery` 等请求 DTO，并返回
|
||||
`*dto.PlanResponse`, `*dto.ListPlansResponse` 等响应 DTO。
|
||||
- **理由**：这与 `monitor`、`device` 和 `pig-farm` 模块的重构决策一致，可以确保应用服务层的接口统一、清晰，并与上层（控制器）和下层（领域/仓库）完全解耦。服务层内部将负责
|
||||
`DTO` 到 `models` 的转换以及 `models` 到 `DTO` 的转换。
|
||||
|
||||
- **决策：将控制器中的业务规则判断和错误处理下沉到服务层**
|
||||
- **理由**：控制器应专注于 HTTP 协议相关的职责。所有业务规则的判断（如计划类型、状态检查、ContentType 自动判断、执行计数器重置）以及对底层错误的具体判断（如 `gorm.ErrRecordNotFound`）都属于业务逻辑范畴，应由服务层处理。服务层将返回更抽象的业务错误，控制器只需根据这些抽象错误进行统一的 HTTP 响应处理。
|
||||
- **决策：将控制器中的业务规则判断和错误处理下沉到服务层**
|
||||
- **理由**：控制器应专注于 HTTP 协议相关的职责。所有业务规则的判断（如计划类型、状态检查、ContentType
|
||||
自动判断、执行计数器重置）以及对底层错误的具体判断（如 `gorm.ErrRecordNotFound`
|
||||
）都属于业务逻辑范畴，应由服务层处理。服务层将返回更抽象的业务错误，控制器只需根据这些抽象错误进行统一的 HTTP 响应处理。
|
||||
|
||||
### Risks / Trade-offs
|
||||
|
||||
- **风险：意外修改或丢失现有业务逻辑**
|
||||
- **描述**：在将控制器中分散的业务逻辑迁移到服务层时，存在逻辑被无意中删除、修改或遗漏的风险，尤其是在处理计划状态转换、执行计数器重置和 `ContentType` 自动判断等复杂逻辑时。
|
||||
- **缓解措施**：
|
||||
1. **逐行迁移与比对**：在迁移过程中，将控制器中的每一段业务逻辑代码逐行复制到服务层，并仔细比对，确保逻辑的等效性。
|
||||
2. **详细注释**：在服务层中对迁移过来的业务逻辑添加详细注释，解释其来源和作用。
|
||||
3. **回归测试**：在完成重构后，必须进行完整的回归测试，确保所有受影响的 API 端点的行为与重构前完全一致。
|
||||
- **风险：意外修改或丢失现有业务逻辑**
|
||||
- **描述**：在将控制器中分散的业务逻辑迁移到服务层时，存在逻辑被无意中删除、修改或遗漏的风险，尤其是在处理计划状态转换、执行计数器重置和
|
||||
`ContentType` 自动判断等复杂逻辑时。
|
||||
- **缓解措施**：
|
||||
1. **逐行迁移与比对**：在迁移过程中，将控制器中的每一段业务逻辑代码逐行复制到服务层，并仔细比对，确保逻辑的等效性。
|
||||
2. **详细注释**：在服务层中对迁移过来的业务逻辑添加详细注释，解释其来源和作用。
|
||||
3. **回归测试**：在完成重构后，必须进行完整的回归测试，确保所有受影响的 API 端点的行为与重构前完全一致。
|
||||
|
||||
### Migration Plan
|
||||
|
||||
1. **创建 `internal/app/service/plan_service.go` 文件**：
|
||||
- 定义 `PlanService` 接口，包含 `CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`, `StartPlan`, `StopPlan` 等方法。
|
||||
- 定义 `planService` 结构体，并实现 `PlanService` 接口。
|
||||
- 在 `planService` 的实现中，将 `plan_controller.go` 中所有相关的业务逻辑（包括 DTO 转换、业务规则判断、对 `planRepo` 和 `analysisPlanTaskManager` 的调用、错误处理）精确迁移到对应的方法中。
|
||||
1. **创建 `internal/app/service/plan_service.go` 文件**：
|
||||
- 定义 `PlanService` 接口，包含 `CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`, `StartPlan`,
|
||||
`StopPlan` 等方法。
|
||||
- 定义 `planService` 结构体，并实现 `PlanService` 接口。
|
||||
- 在 `planService` 的实现中，将 `plan_controller.go` 中所有相关的业务逻辑（包括 DTO 转换、业务规则判断、对 `planRepo` 和
|
||||
`analysisPlanTaskManager` 的调用、错误处理）精确迁移到对应的方法中。
|
||||
|
||||
2. **修改 `internal/app/controller/plan/plan_controller.go`**：
|
||||
- 更新 `Controller` 结构体，将 `planRepo` 和 `analysisPlanTaskManager` 替换为 `service.PlanService`。
|
||||
- 修改 `NewController` 函数，注入 `service.PlanService`。
|
||||
- 简化所有处理器方法，移除所有业务逻辑，只保留请求参数绑定、调用 `service.PlanService` 方法、错误处理和响应构建。
|
||||
2. **修改 `internal/app/controller/plan/plan_controller.go`**：
|
||||
- 更新 `Controller` 结构体，将 `planRepo` 和 `analysisPlanTaskManager` 替换为 `service.PlanService`。
|
||||
- 修改 `NewController` 函数，注入 `service.PlanService`。
|
||||
- 简化所有处理器方法，移除所有业务逻辑，只保留请求参数绑定、调用 `service.PlanService` 方法、错误处理和响应构建。
|
||||
|
||||
3. **修改 `internal/core/component_initializers.go`**：
|
||||
- 在 `AppServices` 结构体中添加 `PlanService service.PlanService` 字段。
|
||||
- 在 `initAppServices` 函数中，初始化 `PlanService` 实例，并将其注入到 `AppServices` 中。
|
||||
3. **修改 `internal/core/component_initializers.go`**：
|
||||
- 在 `AppServices` 结构体中添加 `PlanService service.PlanService` 字段。
|
||||
- 在 `initAppServices` 函数中，初始化 `PlanService` 实例，并将其注入到 `AppServices` 中。
|
||||
|
||||
4. **修改 `internal/app/api/api.go`**：
|
||||
- 更新 `NewAPI` 函数的参数，移除 `planRepository` 和 `analysisTaskManager`，添加 `service.PlanService`。
|
||||
- 更新 `plan.NewController` 的调用，传入新的 `service.PlanService` 依赖。
|
||||
4. **修改 `internal/app/api/api.go`**：
|
||||
- 更新 `NewAPI` 函数的参数，移除 `planRepository` 和 `analysisTaskManager`，添加 `service.PlanService`。
|
||||
- 更新 `plan.NewController` 的调用，传入新的 `service.PlanService` 依赖。
|
||||
|
||||
### Open Questions
|
||||
|
||||
- 暂无。
|
||||
- 暂无。
|
||||
|
||||
---
|
||||
|
||||
## `user` 模块重构设计
|
||||
|
||||
### Context
|
||||
|
||||
`user_controller.go` 当前直接依赖 `repository.UserRepository`、`token.Service` 和 `domain_notify.Service`
|
||||
，并在其方法内部执行了大量本应属于应用服务层的逻辑，包括：
|
||||
|
||||
- **直接的数据库操作**：调用 `userRepo` 的 `Create`, `FindByUsername`, `FindUserForLogin` 等方法。
|
||||
- **领域模型实例化**：通过 `&models.User{...}` 直接创建数据库模型。
|
||||
- **业务规则验证**：例如在 `CreateUser` 中判断用户名是否重复，在 `Login` 中进行密码验证。
|
||||
- **协调领域服务**：在 `Login` 中协调 `tokenService` 生成 JWT，在 `SendTestNotification` 中协调 `domain_notify.Service`
|
||||
发送测试消息。
|
||||
- **复杂的错误处理**：通过 `errors.Is` 和 `gorm.ErrRecordNotFound` 解析底层错误。
|
||||
- **DTO 转换**：在方法末尾将 `models.User` 转换为 `dto.CreateUserResponse` 或 `dto.LoginResponse`。
|
||||
|
||||
这种设计导致控制器与基础设施层和领域层紧密耦合，违反了分层架构的原则。
|
||||
|
||||
### Goals / Non-Goals
|
||||
|
||||
#### Goals
|
||||
|
||||
- **创建应用服务层**：引入一个新的 `internal/app/service/user_service.go` 来封装业务逻辑。
|
||||
- **迁移业务逻辑**：将上述所有在控制器中识别出的业务逻辑和数据处理任务，全部迁移到新的 `UserService` 中。
|
||||
- **简化控制器**：使 `user_controller.go` 只负责 HTTP 请求处理和对新 `UserService` 的调用。
|
||||
- **保持领域服务纯粹**：确保 `internal/domain/token.Service` 和 `internal/domain/notify.Service` 继续专注于核心领域逻辑，不与
|
||||
DTO 发生耦合。
|
||||
|
||||
#### Non-Goals
|
||||
|
||||
- **不修改业务逻辑**：本次重构不涉及任何已有业务规则的变更。所有业务逻辑将原封不动地从控制器迁移到服务层。
|
||||
- **不改变 API 契约**：对外暴露的 API 接口、请求和响应格式保持不变。
|
||||
- **不改变领域服务**：不对 `domain.token.Service` 和 `domain.notify.Service` 的接口和实现进行任何修改。
|
||||
- **不改变仓库层接口**：不对 `internal/infra/repository/user_repository.go` 的接口进行任何修改。
|
||||
- **不涉及 `ListUserHistory` 方法**：该方法已从重构范围中移除。
|
||||
|
||||
### Decisions
|
||||
|
||||
- **决策：引入新的应用服务 `UserService`**
|
||||
- **理由**：这是解决控制器职责过重和分层不清问题的标准做法。该服务将作为应用层门面，协调 `UserRepository`、
|
||||
`token.Service` 和 `domain_notify.Service`，并为控制器提供一个清晰、稳定的接口。
|
||||
- **结构**：`UserService` 将依赖于 `repository.UserRepository`, `token.Service`, `domain_notify.Service` 和
|
||||
`logs.Logger`。
|
||||
|
||||
- **决策：`UserService` 接口全面采用 DTO**
|
||||
- **具体实现**：接口方法将接收 `dto.CreateUserRequest`, `dto.LoginRequest`, `dto.SendTestNotificationRequest` 等请求
|
||||
DTO，并返回 `*dto.CreateUserResponse`, `*dto.LoginResponse` 等响应 DTO。
|
||||
- **理由**：这与 `monitor`、`device`、`pig-farm` 和 `plan` 模块的重构决策一致，可以确保应用服务层的接口统一、清晰，并与上层（控制器）和下层（领域/仓库）完全解耦。服务层内部将负责
|
||||
DTO 到 `models` 的转换以及 `models` 到 DTO 的转换。
|
||||
|
||||
- **决策：将控制器中的业务规则判断和错误处理下沉到服务层**
|
||||
- **理由**：控制器应专注于 HTTP 协议相关的职责。所有业务规则的判断（如用户名重复检查、密码验证）以及对底层错误的具体判断（如
|
||||
`gorm.ErrRecordNotFound`）都属于业务逻辑范畴，应由服务层处理。服务层将返回更抽象的业务错误，控制器只需根据这些抽象错误进行统一的
|
||||
HTTP 响应处理。
|
||||
|
||||
### Risks / Trade-offs
|
||||
|
||||
- **风险：意外修改或丢失现有业务逻辑**
|
||||
- **描述**：在将控制器中分散的业务逻辑迁移到服务层时，存在逻辑被无意中删除、修改或遗漏的风险，尤其是在处理用户创建、登录和通知发送等复杂逻辑时。
|
||||
- **缓解措施**：
|
||||
1. **逐行迁移与比对**：在迁移过程中，将控制器中的每一段业务逻辑代码逐行复制到服务层，并仔细比对，确保逻辑的等效性。
|
||||
2. **详细注释**：在服务层中对迁移过来的业务逻辑添加详细注释，解释其来源和作用。
|
||||
3. **回归测试**：在完成重构后，必须进行完整的回归测试，确保所有受影响的 API 端点的行为与重构前完全一致。
|
||||
|
||||
### Migration Plan
|
||||
|
||||
1. **创建 `internal/app/service/user_service.go` 文件**：
|
||||
- 定义 `UserService` 接口，包含 `CreateUser`, `Login`, `SendTestNotification` 等方法。
|
||||
- 定义 `userService` 结构体，并实现 `UserService` 接口。
|
||||
- 在 `userService` 的实现中，将 `user_controller.go` 中所有相关的业务逻辑（包括 DTO 转换、业务规则判断、对 `userRepo`、
|
||||
`tokenService` 和 `notifyService` 的调用、错误处理）精确迁移到对应的方法中。
|
||||
|
||||
2. **修改 `internal/app/controller/user/user_controller.go`**：
|
||||
- 更新 `Controller` 结构体，将 `userRepo`, `tokenService`, `notifyService` 替换为 `service.UserService`。
|
||||
- 修改 `NewController` 函数，注入 `service.UserService`。
|
||||
- 简化所有处理器方法，移除所有业务逻辑，只保留请求参数绑定、调用 `service.UserService` 方法、错误处理和响应构建。
|
||||
|
||||
3. **修改 `internal/core/component_initializers.go`**：
|
||||
- 在 `AppServices` 结构体中添加 `UserService service.UserService` 字段。
|
||||
- 在 `initAppServices` 函数中，初始化 `UserService` 实例，并将其注入到 `AppServices` 中。
|
||||
|
||||
4. **修改 `internal/app/api/api.go`**：
|
||||
- 更新 `NewAPI` 函数的参数，移除 `userRepo`, `tokenService`, `notifyService`，添加 `service.UserService`。
|
||||
- 更新 `user.NewController` 的调用，传入新的 `service.UserService` 依赖。
|
||||
|
||||
### Open Questions
|
||||
|
||||
- 暂无。
|
||||
|
||||
Reference in New Issue
Block a user