计划服务重构设计方案

1. 目标

将 internal/domain/scheduler 包重构为 internal/domain/plan，并创建一个新的 Service 对象，将原 scheduler 包中的核心调度逻辑集成到 Service 中作为一个子服务，统一由 Service 对外提供服务。此重构旨在提高代码的模块化、可维护性和可测试性，并为后续的“设备删除前校验”功能奠定基础。

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/plan_execution_manager.go:
- 将 Scheduler 结构体更名为 ExecutionManagerImpl。这个名称更准确地反映了它作为计划任务执行的协调者和管理者的具体实现。
- 将 NewScheduler 构造函数更名为 NewExecutionManagerImpl。
- 文件内部所有对 Scheduler 的引用都将更新为 ExecutionManagerImpl。
internal/domain/plan/analysis_plan_task_manager.go:
- 将 AnalysisPlanTaskManager 结构体更名为 AnalysisPlanTaskManagerImpl。
- 将 NewAnalysisPlanTaskManager 构造函数更名为 NewAnalysisPlanTaskManagerImpl。
- 文件内部所有对 AnalysisPlanTaskManager 的引用都将更新为 AnalysisPlanTaskManagerImpl。
定义领域层接口:
- 在 internal/domain/plan 包中定义 ExecutionManager 接口，包含 ExecutionManagerImpl 对外暴露的所有公共方法。
- 在 internal/domain/plan 包中定义 AnalysisPlanTaskManager 接口，包含 AnalysisPlanTaskManagerImpl 对外暴露的所有公共方法。
- ExecutionManagerImpl 和 AnalysisPlanTaskManagerImpl 将分别实现对应的接口。

2.3. 创建 `internal/domain/plan/plan_service.go`

创建新文件 internal/domain/plan/plan_service.go。
定义领域服务接口:
- 在 internal/domain/plan 包中定义 Service 接口，该接口将聚合 ExecutionManager 和 AnalysisPlanTaskManager 的所有公共方法，并由 planServiceImpl 实现这些方法的委托。
实现领域服务:
- 该文件将定义 planServiceImpl 结构体，并包含 ExecutionManager 接口和 AnalysisPlanTaskManager 接口的实例作为其依赖。
- 实现 NewService 构造函数，负责接收 ExecutionManager 接口和 AnalysisPlanTaskManager 接口的实例，并将其注入到 planServiceImpl 中。
- planServiceImpl 将对外提供高层次的 API，这些 API 会协调调用其依赖的接口方法。例如：
  - Service.Start() 方法会调用 ExecutionManager 接口的 Start() 方法。
  - Service.Stop() 方法会调用 ExecutionManager 接口的 Stop() 方法。
  - Service.RefreshPlanTriggers() 方法会调用 AnalysisPlanTaskManager 接口的 Refresh() 方法。
  - Service.CreateOrUpdateTrigger() 方法会调用 AnalysisPlanTaskManager 接口的 CreateOrUpdateTrigger() 方法。
  - Service.EnsureAnalysisTaskDefinition() 方法会调用 AnalysisPlanTaskManager 接口的 EnsureAnalysisTaskDefinition() 方法。
  - 未来所有与计划相关的领域操作，都将通过 Service 接口进行。

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.ExecutionManagerImpl 和 plan.AnalysisPlanTaskManagerImpl 的具体实例。
- 然后，将这些具体实例作为 plan.ExecutionManager 接口和 plan.AnalysisPlanTaskManager 接口类型传递给 plan.NewService 构造函数，创建 planServiceImpl 实例。
- 最终，plan.NewService 返回 plan.Service 接口类型。
- 应用程序的其他部分将通过 plan.Service 接口来访问计划相关的逻辑，而不是直接访问底层的管理器或其具体实现。

3. 优势

职责分离清晰： internal/domain/plan 包专注于计划领域的核心逻辑和管理，并提供统一的 Service 接口作为领域服务的入口。
符合领域驱动设计： 领域层包含核心业务逻辑和管理器，应用层（如果需要）作为领域层的协调者。
与现有项目风格一致： 借鉴 domain/pig 包的模式，提高了项目内部的一致性。
可测试性增强： Service 可以更容易地进行单元测试，因为其依赖的接口可以被模拟。
可维护性提高： 当计划相关的业务逻辑发生变化时，可以更精确地定位到需要修改的组件。
松耦合： Service 不依赖于具体的实现，而是依赖于接口，提高了系统的灵活性和可扩展性。

4. 验证和测试

在完成所有修改后，需要运行项目并进行测试，确保调度器功能正常，没有引入新的错误。

5.5 KiB Raw Blame History Unescape Escape