任务2.4
This commit is contained in:
@@ -229,3 +229,82 @@
|
||||
### Open Questions
|
||||
|
||||
- 暂无。
|
||||
|
||||
---
|
||||
|
||||
## `plan` 模块重构设计
|
||||
|
||||
### Context
|
||||
|
||||
`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` 的重置逻辑。
|
||||
|
||||
这种设计导致控制器层职责过重，业务逻辑分散，难以维护和测试。
|
||||
|
||||
### Goals / Non-Goals
|
||||
|
||||
#### Goals
|
||||
|
||||
- **创建应用服务层**：引入一个新的 `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` 的接口进行任何修改。
|
||||
|
||||
### Decisions
|
||||
|
||||
- **决策：引入新的应用服务 `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` 的转换。
|
||||
|
||||
- **决策：将控制器中的业务规则判断和错误处理下沉到服务层**
|
||||
- **理由**：控制器应专注于 HTTP 协议相关的职责。所有业务规则的判断（如计划类型、状态检查、ContentType 自动判断、执行计数器重置）以及对底层错误的具体判断（如 `gorm.ErrRecordNotFound`）都属于业务逻辑范畴，应由服务层处理。服务层将返回更抽象的业务错误，控制器只需根据这些抽象错误进行统一的 HTTP 响应处理。
|
||||
|
||||
### Risks / Trade-offs
|
||||
|
||||
- **风险：意外修改或丢失现有业务逻辑**
|
||||
- **描述**：在将控制器中分散的业务逻辑迁移到服务层时，存在逻辑被无意中删除、修改或遗漏的风险，尤其是在处理计划状态转换、执行计数器重置和 `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` 的调用、错误处理）精确迁移到对应的方法中。
|
||||
|
||||
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` 中。
|
||||
|
||||
4. **修改 `internal/app/api/api.go`**：
|
||||
- 更新 `NewAPI` 函数的参数，移除 `planRepository` 和 `analysisTaskManager`，添加 `service.PlanService`。
|
||||
- 更新 `plan.NewController` 的调用，传入新的 `service.PlanService` 依赖。
|
||||
|
||||
### Open Questions
|
||||
|
||||
- 暂无。
|
||||
|
||||
@@ -65,32 +65,32 @@
|
||||
|
||||
### 2.4 `plan` 模块
|
||||
|
||||
- [ ] 2.4.1 **创建并修改 `internal/app/service/plan_service.go`：**
|
||||
- [ ] 定义 `PlanService` 接口，包含 `CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`,
|
||||
- [x] 2.4.1 **创建并修改 `internal/app/service/plan_service.go`：**
|
||||
- [x] 定义 `PlanService` 接口，包含 `CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`,
|
||||
`StartPlan`, `StopPlan` 等方法。
|
||||
- [ ] 为 `CreatePlan`, `UpdatePlan` 方法定义并接收 DTO 作为输入。
|
||||
- [ ] 将 `GetPlanByID`, `ListPlans` 方法的返回值 `models.Plan` 或 `[]models.Plan` 替换为 `dto.PlanResponse` 或
|
||||
- [x] 为 `CreatePlan`, `UpdatePlan` 方法定义并接收 DTO 作为输入。
|
||||
- [x] 将 `GetPlanByID`, `ListPlans` 方法的返回值 `models.Plan` 或 `[]models.Plan` 替换为 `dto.PlanResponse` 或
|
||||
`[]dto.PlanResponse`。
|
||||
- [ ] 调整 `ListPlans` 方法的 `opts repository.ListPlansOptions` 参数替换为服务层自定义的查询 DTO 或一系列基本参数。
|
||||
- [ ] 调整 `DeletePlan`, `StartPlan`, `StopPlan` 方法，使其接收 DTO 或基本参数，并封装所有业务逻辑。
|
||||
- [ ] 实现 `PlanService` 接口。
|
||||
- [ ] 在服务层内部将输入 DTO 转换为 `models` 对象。
|
||||
- [ ] 在服务层内部将 `repository` 返回的 `models` 对象转换为 `dto.XxxResponse`。
|
||||
- [ ] 将 `internal/app/controller/plan/plan_controller.go` 中所有的业务规则判断（计划类型检查、状态检查、执行计数器重置、ContentType
|
||||
- [x] 调整 `ListPlans` 方法的 `opts repository.ListPlansOptions` 参数替换为服务层自定义的查询 DTO 或一系列基本参数。
|
||||
- [x] 调整 `DeletePlan`, `StartPlan`, `StopPlan` 方法，使其接收 DTO 或基本参数，并封装所有业务逻辑。
|
||||
- [x] 实现 `PlanService` 接口。
|
||||
- [x] 在服务层内部将输入 DTO 转换为 `models` 对象。
|
||||
- [x] 在服务层内部将 `repository` 返回的 `models` 对象转换为 `dto.XxxResponse`。
|
||||
- [x] 将 `internal/app/controller/plan/plan_controller.go` 中所有的业务规则判断（计划类型检查、状态检查、执行计数器重置、ContentType
|
||||
自动判断）移入服务层。
|
||||
- [ ] 将 `internal/app/controller/plan/plan_controller.go` 中对 `repository` 方法的直接调用移入服务层。
|
||||
- [ ] 将 `internal/app/controller/plan/plan_controller.go` 中对 `analysisPlanTaskManager` 的协调移入服务层。
|
||||
- [ ] 将 `internal/app/controller/plan/plan_controller.go` 中处理仓库层特有错误（`gorm.ErrRecordNotFound`）的逻辑移入服务层。
|
||||
- [ ] 2.4.2 **修改 `internal/app/controller/plan/plan_controller.go`：**
|
||||
- [ ] 引入并使用新创建的 `plan_service`。
|
||||
- [ ] 移除控制器中直接创建 `models.Plan` 对象和 `repository.ListPlansOptions` 的逻辑。
|
||||
- [ ] 移除控制器中所有的业务规则判断。
|
||||
- [ ] 移除控制器中直接调用 `repository` 方法的逻辑。
|
||||
- [ ] 移除控制器中直接协调 `analysisPlanTaskManager` 的逻辑。
|
||||
- [ ] 移除控制器中直接处理仓库层特有错误的逻辑。
|
||||
- [ ] 调整服务层方法的调用，使其接收新的服务层输入 DTO 或基本参数，并直接处理服务层返回的 `dto.XxxResponse`。
|
||||
- [ ] 2.4.3 **修改 `internal/core/component_initializers.go`**：创建并提供新的 `PlanService`。
|
||||
- [ ] 2.4.4 **修改 `internal/app/api/api.go`**：更新 `PlanController` 的依赖注入。
|
||||
- [x] 将 `internal/app/controller/plan/plan_controller.go` 中对 `repository` 方法的直接调用移入服务层。
|
||||
- [x] 将 `internal/app/controller/plan/plan_controller.go` 中对 `analysisPlanTaskManager` 的协调移入服务层。
|
||||
- [x] 将 `internal/app/controller/plan/plan_controller.go` 中处理仓库层特有错误（`gorm.ErrRecordNotFound`）的逻辑移入服务层。
|
||||
- [x] 2.4.2 **修改 `internal/app/controller/plan/plan_controller.go`：**
|
||||
- [x] 引入并使用新创建的 `plan_service`。
|
||||
- [x] 移除控制器中直接创建 `models.Plan` 对象和 `repository.ListPlansOptions` 的逻辑。
|
||||
- [x] 移除控制器中所有的业务规则判断。
|
||||
- [x] 移除控制器中直接调用 `repository` 方法的逻辑。
|
||||
- [x] 移除控制器中直接协调 `analysisPlanTaskManager` 的逻辑。
|
||||
- [x] 移除控制器中直接处理仓库层特有错误的逻辑。
|
||||
- [x] 调整服务层方法的调用，使其接收新的服务层输入 DTO 或基本参数，并直接处理服务层返回的 `dto.XxxResponse`。
|
||||
- [x] 2.4.3 **修改 `internal/core/component_initializers.go`**：创建并提供新的 `PlanService`。
|
||||
- [x] 2.4.4 **修改 `internal/app/api/api.go`**：更新 `PlanController` 的依赖注入。
|
||||
|
||||
### 2.5 `user` 模块
|
||||
|
||||
|
||||
Reference in New Issue
Block a user