实现任务2.2

2025-10-31 15:38:10 +08:00
parent db11438f5c
commit 0c35e2ce7d
4 changed files with 594 additions and 463 deletions
--- a/openspec/changes/refactor-business-logic-layering/design.md
+++ b/openspec/changes/refactor-business-logic-layering/design.md
@@ -1,10 +1,14 @@
+# `monitor` 模块重构设计
+
 ## Context

-当前, `monitor` 模块的数据转换逻辑（例如, 将 `repository` 层返回的 `models` 实体转换为 `dto` 对象）主要存在于 `internal/app/controller/monitor/monitor_controller.go` 文件中。
+当前, `monitor` 模块的数据转换逻辑（例如, 将 `repository` 层返回的 `models` 实体转换为 `dto` 对象）主要存在于
+`internal/app/controller/monitor/monitor_controller.go` 文件中。

 这种设计导致了以下问题：

- **职责不清**：控制器层承担了过多的数据处理任务, 违反了“关注点分离”原则。控制器应主要负责处理 HTTP 请求、参数绑定和调用服务, 而非执行业务或数据转换逻辑。
+- **职责不清**：控制器层承担了过多的数据处理任务, 违反了“关注点分离”原则。控制器应主要负责处理 HTTP 请求、参数绑定和调用服务,
+  而非执行业务或数据转换逻辑。
 - **代码重复**：如果未来有其他服务需要类似的数据转换, 可能会导致代码重复。
 - **可测试性差**：由于转换逻辑与 `echo.Context` 紧密耦合, 对其进行单元测试变得更加复杂。

@@ -12,7 +16,8 @@

 ### Goals

- **迁移数据转换逻辑**：将 `monitor` 模块中所有的数据转换逻辑从控制器层 (`monitor_controller.go`) 迁移到服务层 (`monitor_service.go`)。
+- **迁移数据转换逻辑**：将 `monitor` 模块中所有的数据转换逻辑从控制器层 (`monitor_controller.go`) 迁移到服务层 (
+  `monitor_service.go`)。
 - **统一服务层接口**：使服务层的方法直接接收请求 DTO, 并返回响应 DTO, 从而使服务本身成为一个完整的、自包含的业务逻辑单元。
 - **简化控制器**：精简控制器中的代码, 使其只关注其核心职责：请求处理和响应发送。

@@ -25,39 +30,131 @@
 ## Decisions

 - **决策：在服务层完成 DTO 转换**
-  - **理由**：服务层是封装业务逻辑的核心, 将数据从领域模型 (`models`) 转换为外部表示 (`dto`) 是业务服务的一部分。这样做可以确保任何调用该服务的客户端（无论是控制器、gRPC 服务还是其他服务）都能获得一致的、随时可用的数据结构。
-  - **替代方案**：曾考虑在 `dto` 包中创建一个独立的转换层。但最终认为, 将转换逻辑内聚到服务层更能体现其业务属性, 因为服务层最清楚需要暴露哪些数据以及如何组织这些数据。
+    - **理由**：服务层是封装业务逻辑的核心, 将数据从领域模型 (`models`) 转换为外部表示 (`dto`)
+      是业务服务的一部分。这样做可以确保任何调用该服务的客户端（无论是控制器、gRPC 服务还是其他服务）都能获得一致的、随时可用的数据结构。
+    - **替代方案**：曾考虑在 `dto` 包中创建一个独立的转换层。但最终认为, 将转换逻辑内聚到服务层更能体现其业务属性,
+      因为服务层最清楚需要暴露哪些数据以及如何组织这些数据。

 - **决策：修改服务层接口以直接处理 DTO**
-  - **具体实现**：计划将 `MonitorService` 接口中的所有 `List...` 方法签名从 `ListSomething(opts repository.ListOptions, page, pageSize int) ([]models.Something, int64, error)` 修改为 `ListSomething(req *dto.ListSomethingRequest) (*dto.ListSomethingResponse, error)`。
-  - **理由**：这种设计将极大地简化控制器与服务之间的交互。控制器将不再需要手动构建 `repository.ListOptions` 或在调用服务后手动组装响应 DTO。它只需传递请求 DTO, 然后直接使用服务返回的响应 DTO, 从而实现彻底的解耦。
+    - **具体实现**：计划将 `MonitorService` 接口中的所有 `List...` 方法签名从
+      `ListSomething(opts repository.ListOptions, page, pageSize int) ([]models.Something, int64, error)` 修改为
+      `ListSomething(req *dto.ListSomethingRequest) (*dto.ListSomethingResponse, error)`。
+    - **理由**：这种设计将极大地简化控制器与服务之间的交互。控制器将不再需要手动构建 `repository.ListOptions`
+      或在调用服务后手动组装响应 DTO。它只需传递请求 DTO, 然后直接使用服务返回的响应 DTO, 从而实现彻底的解耦。

 ## Risks / Trade-offs

 - **风险：意外修改或丢失现有业务逻辑**
-  - **描述**：在移动代码的过程中, 尤其是像 `ListPlanExecutionLogs` 这样包含特定业务逻辑（获取关联 `plans`）的方法, 存在逻辑被无意中删除或修改的风险。
-  - **缓解措施**：
-    1.  **代码审查**：在重构前后仔细比对原有逻辑, 确保其被完整地迁移到了新的服务层方法中。
-    2.  **保留原有实现**：在新的服务层方法中, 将严格按照控制器中原有的顺序——先构建查询选项, 再调用仓库, 最后进行数据转换——来组织代码, 确保逻辑的等效性。
-    3.  **测试**：在完成重构后, 必须进行完整的回归测试, 确保所有受影响的 API 端点的行为与重构前完全一致。
+    - **描述**：在移动代码的过程中, 尤其是像 `ListPlanExecutionLogs` 这样包含特定业务逻辑（获取关联 `plans`）的方法,
+      存在逻辑被无意中删除或修改的风险。
+    - **缓解措施**：
+        1. **代码审查**：在重构前后仔细比对原有逻辑, 确保其被完整地迁移到了新的服务层方法中。
+        2. **保留原有实现**：在新的服务层方法中, 将严格按照控制器中原有的顺序——先构建查询选项, 再调用仓库,
+           最后进行数据转换——来组织代码, 确保逻辑的等效性。
+        3. **测试**：在完成重构后, 必须进行完整的回归测试, 确保所有受影响的 API 端点的行为与重构前完全一致。

 ## Migration Plan

 本次重构将按以下步骤进行：

-1.  **修改服务层 (`internal/app/service/monitor_service.go`)**
+1. **修改服务层 (`internal/app/service/monitor_service.go`)**
    - **更新接口**：修改 `MonitorService` 接口中所有 `List...` 方法的签名, 使其接收请求 DTO 并返回响应 DTO。
-    - **实现数据转换**：在每个 `List...` 方法的实现中, 添加从请求 DTO 到 `repository.ListOptions` 的转换逻辑, 以及从业仓库返回的 `models` 到响应 DTO 的转换逻辑。对于 `ListPlanExecutionLogs` 等方法, 确保原有的附加业务逻辑（如查询关联 `Plan` 信息）被完整保留。
+    - **实现数据转换**：在每个 `List...` 方法的实现中, 添加从请求 DTO 到 `repository.ListOptions` 的转换逻辑, 以及从业仓库返回的
+      `models` 到响应 DTO 的转换逻辑。对于 `ListPlanExecutionLogs` 等方法, 确保原有的附加业务逻辑（如查询关联 `Plan`
+      信息）被完整保留。

-2.  **修改控制器层 (`internal/app/controller/monitor/monitor_controller.go`)**
+2. **修改控制器层 (`internal/app/controller/monitor/monitor_controller.go`)**
    - **移除转换逻辑**：删除所有手动构建 `repository.ListOptions` 和调用 `dto.NewList...Response` 的代码。
    - **更新服务调用**：修改对 `monitorService` 的调用, 使其传递完整的请求 DTO, 并直接处理返回的响应 DTO。
    - **简化日志**：调整日志记录, 以便从服务层返回的 DTO 中获取列表长度和总记录数。

-3.  **验证**
+3. **验证**
    - 通过静态代码分析和审查, 确认代码风格和逻辑的正确性。
    - 进行完整的单元测试和集成测试, 以确保重构没有引入任何回归问题。

 ## Open Questions

 - 暂无。
+
+---
+
+## `device` 模块重构设计
+
+### Context
+
+`device_controller.go` 当前直接依赖多个 `repository` 和 `domain.Service`，并在其方法内部执行了大量本应属于应用服务层的逻辑，包括：
+
+- **直接的数据库操作**：调用 `repository` 的 `Create`, `Update`, `Delete`, `Find` 等方法。
+- **领域模型实例化**：通过 `&models.Device{...}` 直接创建数据库模型。
+- **内部字段序列化**：对 `Properties`, `Commands`, `Values` 等字段执行 `json.Marshal`。
+- **业务规则验证**：调用 `model.SelfCheck()`。
+- **复杂的错误处理**：通过 `errors.Is` 和 `strings.Contains` 解析底层数据库错误。
+- **DTO 转换**：在方法末尾调用 `dto.New...Response`。
+
+这种设计导致控制器与基础设施层和领域层紧密耦合，违反了分层架构的原则。
+
+### Goals / Non-Goals
+
+#### Goals
+
+- **创建应用服务层**：引入一个新的 `internal/app/service/device_service.go` 来封装业务逻辑。
+- **迁移业务逻辑**：将上述所有在控制器中识别出的业务逻辑和数据处理任务，全部迁移到新的 `DeviceService` 中。
+- **简化控制器**：使 `device_controller.go` 只负责 HTTP 请求处理和对新 `DeviceService` 的调用。
+- **保持领域服务纯粹**：确保 `internal/domain/device/device_service.go` 继续专注于核心领域逻辑，不与 DTO 发生耦合。
+
+#### Non-Goals
+
+- **不改变领域服务**：不对 `domain.device.Service` 的接口和实现进行任何修改。
+- **不改变 API 契约**：对外暴露的 API 接口、请求和响应格式保持不变。
+
+### Decisions
+
+- **决策：引入新的应用服务 `DeviceService`**
+    - **理由**：这是解决控制器职责过重和分层不清问题的标准做法。该服务将作为应用层门面，协调 `repository` 和
+      `domain.Service`，并为控制器提供一个清晰、稳定的接口。
+    - **结构**：`DeviceService` 将依赖于 `DeviceRepository`, `AreaControllerRepository`, `DeviceTemplateRepository` 和
+      `domain.device.Service`。
+
+- **决策：`DeviceService` 接口全面采用 DTO**
+    - **具体实现**：接口方法将接收 `dto.Create...Request` 等请求 DTO，并返回 `*dto....Response` 响应 DTO。
+    - **理由**：这与 `monitor` 模块的重构决策一致，可以确保应用服务层的接口统一、清晰，并与上层（控制器）和下层（领域/仓库）完全解耦。
+
+### Migration Plan
+
+1. **创建 `internal/app/service/device_service.go` 文件**
+    - 定义 `DeviceService` 接口，为控制器中的每个处理器方法（`CreateDevice`, `UpdateDevice`, `GetDevice`, `ListDevices`,
+      `DeleteDevice`, `ManualControl` 等）创建相应的方法。
+    - 定义 `deviceService` 结构体，并实现 `DeviceService` 接口。
+    - **`Create/Update` 方法实现**：
+        1. 接收请求 DTO。
+        2. 执行 `json.Marshal` 转换 `Properties` 等字段。
+        3. 创建 `models.Xxx` 实例。
+        4. 调用 `model.SelfCheck()`。
+        5. 调用 `repository.Create/Update`。
+        6. 调用 `repository.FindByID` 重新加载模型（确保关联数据完整）。
+        7. 调用 `dto.New...Response` 将模型转换为响应 DTO 并返回。
+    - **`Get/List` 方法实现**：
+        1. 调用 `repository.Find/List`。
+        2. 调用 `dto.New...Response` 转换并返回。
+    - **`Delete` 方法实现**：
+        1. 调用 `repository.Delete`。
+        2. 捕获并转换特定的“资源被使用”错误。
+    - **`ManualControl` 方法实现**：
+        1. 调用 `repository.FindByIDString` 加载模型。
+        2. 实现 `action` 字符串到 `device.DeviceAction` 的映射。
+        3. 调用 `domain.device.Service.Switch/Collect`。
+
+2. **修改 `internal/app/controller/device/device_controller.go`**
+    - **更新依赖**：将 `Controller` 的依赖从多个 `repository` 和 `domain.Service` 替换为唯一的
+      `app/service.DeviceService`。
+    - **简化所有处理器方法**：
+        1. 移除所有业务逻辑（`json.Marshal`, `SelfCheck`, `repository` 调用, `dto` 转换等）。
+        2. 每个方法仅保留：参数绑定、调用 `c.deviceService.Method(req)`、错误处理和成功响应。
+
+3. **更新依赖注入**
+    - 在 `cmd/server/wire.go` (或项目中的依赖注入配置处) 更新 `DeviceController` 的创建逻辑，为其注入新创建的
+      `DeviceService`。
+
+### Open Questions
+
+- 暂无。
--- a/openspec/changes/refactor-business-logic-layering/tasks.md
+++ b/openspec/changes/refactor-business-logic-layering/tasks.md
@@ -1,7 +1,8 @@
 ## 1. 准备工作

 - [ ] 1.1 阅读并理解 `openspec/changes/refactor-business-logic-layering/proposal.md`。
- [ ] 1.2 阅读并理解 'AGENTS.md'
+- [ ] 1.2 阅读并理解 `openspec/changes/refactor-business-logic-layering/design.md`。
+- [ ] 1.3 阅读并理解 'AGENTS.md'

 ## 2. 统一服务层接口输入输出为 DTO

@@ -20,36 +21,36 @@

 ### 2.2 `device` 模块

- [ ] 2.2.1 **创建并修改 `internal/app/service/device_service.go`：**
-    - [ ] 定义 `DeviceService` 接口，包含 `CreateDevice`, `UpdateDevice`, `CreateAreaController`, `UpdateAreaController`,
+- [x] 2.2.1 **创建并修改 `internal/app/service/device_service.go`：**
+    - [x] 定义 `DeviceService` 接口，包含 `CreateDevice`, `UpdateDevice`, `CreateAreaController`, `UpdateAreaController`,
      `CreateDeviceTemplate`, `UpdateDeviceTemplate`, `GetDevice`, `ListDevices`, `GetAreaController`,
      `ListAreaControllers`, `GetDeviceTemplate`, `ListDeviceTemplates`, `ManualControl` 等方法。
-    - [ ] 为 `CreateDevice`, `UpdateDevice`, `CreateAreaController`, `UpdateAreaController`, `CreateDeviceTemplate`,
+    - [x] 为 `CreateDevice`, `UpdateDevice`, `CreateAreaController`, `UpdateAreaController`, `CreateDeviceTemplate`,
      `UpdateDeviceTemplate`, `ManualControl` 方法定义并接收 DTO 作为输入。
-    - [ ] 将 `GetDevice`, `ListDevices`, `GetAreaController`, `ListAreaControllers`, `GetDeviceTemplate`,
+    - [x] 将 `GetDevice`, `ListDevices`, `GetAreaController`, `ListAreaControllers`, `GetDeviceTemplate`,
      `ListDeviceTemplates` 方法的返回值 `models.Xxx` 或 `[]models.Xxx` 替换为 `dto.XxxResponse` 或 `[]dto.XxxResponse`。
-    - [ ] 实现 `DeviceService` 接口。
-    - [ ] 在此服务层内部将输入 DTO 转换为 `models` 对象。
-    - [ ] 在此服务层内部将 `repository` 或 `domain` 层返回的 `models` 对象转换为 `dto.XxxResponse`。
-    - [ ] 将控制器中 `SelfCheck()` 验证逻辑移入此服务层。
-    - [ ] 将控制器中 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑移入此服务层。
-    - [ ] 将控制器中 `ManualControl` 的业务逻辑（如动作映射）移入此服务层。
-    - [ ] 将控制器中直接调用 `repository` 方法的逻辑移入此服务层。
-    - [ ] 将控制器中通过检查 `repository` 错误信息处理业务规则的逻辑移入此服务层。
-    - [ ] 调整此服务层对 `internal/domain/device.Service` 的调用，确保传递的是 `models` 或领域对象，而不是 DTO。
- [ ] 2.2.2 **修改 `internal/app/controller/device/device_controller.go`：**
-    - [ ] 引入并使用新创建的 `internal/app/service.DeviceService`。
-    - [ ] 移除控制器中直接创建 `models.Device`, `models.AreaController`, `models.DeviceTemplate` 对象的逻辑。
-    - [ ] 移除控制器中直接调用 `SelfCheck()` 的逻辑。
-    - [ ] 移除控制器中直接调用 `repository` 方法的逻辑。
-    - [ ] 移除控制器中通过检查 `repository` 错误信息处理业务规则的逻辑。
-    - [ ] 移除控制器中 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑。
-    - [ ] 调整服务层方法的调用，使其接收新的服务层输入 DTO 或基本参数，并直接处理服务层返回的 `dto.XxxResponse`。
- [ ] 2.2.3 **保持 `internal/domain/device/device_service.go` 和 `internal/domain/device/general_device_service.go`
+    - [x] 实现 `DeviceService` 接口。
+    - [x] 在此服务层内部将输入 DTO 转换为 `models` 对象。
+    - [x] 在此服务层内部将 `repository` 或 `domain` 层返回的 `models` 对象转换为 `dto.XxxResponse`。
+    - [x] 将控制器中 `SelfCheck()` 验证逻辑移入此服务层。
+    - [x] 将控制器中 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑移入此服务层。
+    - [x] 将控制器中 `ManualControl` 的业务逻辑（如动作映射）移入此服务层。
+    - [x] 将控制器中直接调用 `repository` 方法的逻辑移入此服务层。
+    - [x] 将控制器中通过检查 `repository` 错误信息处理业务规则的逻辑移入此服务层。
+    - [x] 调整此服务层对 `internal/domain/device.Service` 的调用，确保传递的是 `models` 或领域对象，而不是 DTO。
+- [x] 2.2.2 **修改 `internal/app/controller/device/device_controller.go`：**
+    - [x] 引入并使用新创建的 `internal/app/service.DeviceService`。
+    - [x] 移除控制器中直接创建 `models.Device`, `models.AreaController`, `models.DeviceTemplate` 对象的逻辑。
+    - [x] 移除控制器中直接调用 `SelfCheck()` 的逻辑。
+    - [x] 移除控制器中直接调用 `repository` 方法的逻辑。
+    - [x] 移除控制器中通过检查 `repository` 错误信息处理业务规则的逻辑。
+    - [x] 移除控制器中 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑。
+    - [x] 调整服务层方法的调用，使其接收新的服务层输入 DTO 或基本参数，并直接处理服务层返回的 `dto.XxxResponse`。
+- [x] 2.2.3 **保持 `internal/domain/device/device_service.go` 和 `internal/domain/device/general_device_service.go`
  专注于领域逻辑：**
-    - [ ] 确保 `internal/domain/device/device_service.go` 接口方法和 `internal/domain/device/general_device_service.go`
+    - [x] 确保 `internal/domain/device/device_service.go` 接口方法和 `internal/domain/device/general_device_service.go`
      实现方法不直接接收或返回 DTO。
-    - [ ] 调整 `internal/domain/device/general_device_service.go` 的方法签名和内部逻辑，以适应其调用方（新的
+    - [x] 调整 `internal/domain/device/general_device_service.go` 的方法签名和内部逻辑，以适应其调用方（新的
      `internal/app/service.DeviceService`）的调整，如果需要的话。

 ### 2.3 `pig-farm` 模块