修改方案

design/verification-before-device-deletion/plan_service_refactor.md

@@ -0,0 +1,65 @@
+# 计划服务重构设计方案
+
+## 1. 目标
+
+将 `internal/domain/scheduler` 包重构为 `internal/domain/plan`，并创建一个新的 `PlanService` 对象，将原 `scheduler` 包中的核心调度逻辑集成到 `PlanService` 中作为一个子服务，统一由 `PlanService` 对外提供服务。此重构旨在提高代码的模块化、可维护性和可测试性，并为后续的“设备删除前校验”功能奠定基础。
+
+## 2. 方案详情
+
+### 2.1. 包重命名
+
+*   将 `internal/domain/scheduler` 目录重命名为 `internal/domain/plan`。
+*   修改 `internal/domain/plan` 目录下所有 Go 文件中的 `package scheduler` 为 `package plan`。
+*   更新 `internal/domain/plan` 目录下所有 Go 文件中所有引用 `git.huangwc.com/pig/pig-farm-controller/internal/domain/scheduler` 的导入路径为 `git.huangwc.com/pig/pig-farm-controller/internal/domain/plan`。
+
+### 2.2. `internal/domain/plan` 包内部结构调整
+
+*   **`internal/domain/plan/task.go`**:
+    *   保持不变。它定义了任务的接口和工厂，是领域内的核心抽象。
+
+*   **`internal/domain/plan/scheduler.go`**:
+    *   将 `Scheduler` 结构体更名为 `PlanExecutionManagerImpl`。这个名称更准确地反映了它作为计划任务执行的协调者和管理者的具体实现。
+    *   将 `NewScheduler` 构造函数更名为 `NewPlanExecutionManagerImpl`。
+    *   文件内部所有对 `Scheduler` 的引用都将更新为 `PlanExecutionManagerImpl`。
+
+*   **`internal/domain/plan/analysis_plan_task_manager.go`**:
+    *   将 `AnalysisPlanTaskManager` 结构体更名为 `AnalysisPlanTaskManagerImpl`。
+    *   将 `NewAnalysisPlanTaskManager` 构造函数更名为 `NewAnalysisPlanTaskManagerImpl`。
+    *   文件内部所有对 `AnalysisPlanTaskManager` 的引用都将更新为 `AnalysisPlanTaskManagerImpl`。
+
+*   **定义接口**:
+    *   在 `internal/domain/plan` 包中定义 `PlanExecutionManager` 接口，包含 `PlanExecutionManagerImpl` 对外暴露的所有公共方法。
+    *   在 `internal/domain/plan` 包中定义 `AnalysisPlanTaskManager` 接口，包含 `AnalysisPlanTaskManagerImpl` 对外暴露的所有公共方法。
+    *   `PlanExecutionManagerImpl` 和 `AnalysisPlanTaskManagerImpl` 将分别实现对应的接口。
+
+### 2.3. 创建 `internal/app/service/plan_service.go`
+
+*   创建新文件 `internal/app/service/plan_service.go`。
+*   该文件将定义 `PlanService` 结构体，并包含 `plan.PlanExecutionManager` 接口和 `plan.AnalysisPlanTaskManager` 接口的实例作为其依赖。
+*   实现 `NewPlanService` 构造函数，负责接收 `plan.PlanExecutionManager` 接口和 `plan.AnalysisPlanTaskManager` 接口的实例，并将其注入到 `PlanService` 中。
+*   `PlanService` 将对外提供高层次的 API，这些 API 会协调调用其依赖的接口方法。例如：
+    *   `PlanService.Start()` 方法会调用 `PlanExecutionManager` 接口的 `Start()` 方法。
+    *   `PlanService.Stop()` 方法会调用 `PlanExecutionManager` 接口的 `Stop()` 方法。
+    *   `PlanService.RefreshPlanTriggers()` 方法会调用 `AnalysisPlanTaskManager` 接口的 `Refresh()` 方法。
+    *   未来所有与计划相关的应用层操作，都将通过 `PlanService` 进行。
+
+### 2.4. 调整依赖注入和引用
+
+*   **查找并替换导入路径：** 使用 `grep` 命令查找整个项目中所有引用 `git.huangwc.com/pig/pig-farm-controller/internal/domain/scheduler` 的地方，并将其替换为 `git.huangwc.com/pig/pig-farm-controller/internal/domain/plan`。
+*   **更新 `internal/core/component_initializers.go`**:
+    *   在初始化阶段，我们将创建 `plan.PlanExecutionManagerImpl` 和 `plan.AnalysisPlanTaskManagerImpl` 的具体实例。
+    *   然后，将这些具体实例作为 `plan.PlanExecutionManager` 接口和 `plan.AnalysisPlanTaskManager` 接口类型传递给 `service.NewPlanService` 构造函数，创建 `PlanService` 实例。
+    *   应用程序的其他部分将通过 `PlanService` 来访问计划相关的逻辑，而不是直接访问底层的管理器或其具体实现。
+
+## 3. 优势
+
+*   **职责分离清晰：** `internal/domain/plan` 包专注于计划领域的核心逻辑和管理，而 `internal/app/service` 包则负责应用层的业务编排和对外接口。
+*   **符合领域驱动设计：** 领域层包含核心业务逻辑和管理器，应用层作为领域层的协调者。
+*   **与现有项目风格一致：** 借鉴 `domain/pig` 包的模式，提高了项目内部的一致性。
+*   **可测试性增强：** `PlanService` 可以更容易地进行单元测试，因为其依赖的接口可以被模拟。
+*   **可维护性提高：** 当计划相关的业务逻辑发生变化时，可以更精确地定位到需要修改的组件。
+*   **松耦合：** `PlanService` 不依赖于具体的实现，而是依赖于接口，提高了系统的灵活性和可扩展性。
+
+## 4. 验证和测试
+
+在完成所有修改后，需要运行项目并进行测试，确保调度器功能正常，没有引入新的错误。