refactor(service): 统一Service缓存为VO对象并优化关联实体处理

重构Service类实现，将QueryService泛型参数调整为VO类型，确保缓存VO对象而非实体。优化关联实体处理逻辑，减少重复代码。修改findById方法返回VO对象，新增getById方法获取实体。更新相关调用点以适配新接口。

调整WebSocket处理、控制器及Service实现，确保数据类型一致性。完善文档记录重构过程及发现的问题。为后续优化提供基础架构支持。

docs/task/server模块service缓存调整为Vo对象/ALIGNMENT_server_service_cache_vo.md

@@ -0,0 +1,151 @@
+# Server模块Service缓存调整为Vo对象 - ALIGNMENT文档
+
+## 1. 项目上下文分析
+
+### 1.1 项目结构
+
+Contract-Manager是一个基于Java技术栈的合同管理系统，包含三个主要模块：
+
+- **server模块**：基于Spring Boot 3.3.7的后端服务，负责数据持久化、业务逻辑处理和WebSocket通信
+- **client模块**：基于JavaFX 21的桌面客户端，负责用户界面和与server模块的通信
+- **common模块**：公共组件库，被server和client模块共同依赖
+
+### 1.2 技术栈
+
+**server模块**：
+- Java 21
+- Spring Boot 3.3.7
+- Spring Data JPA 3.3.7
+- MySQL 8.0.33
+- Lombok 1.18.32
+- POI 5.2.5
+- PDFBox 3.0.1
+- Redis（用于缓存）
+
+### 1.3 架构模式
+
+系统采用经典的三层架构：
+- **数据访问层**：Repository接口，负责数据持久化
+- **业务逻辑层**：Service类，负责业务逻辑处理和缓存管理
+- **表示层**：Controller和WebSocket服务，负责请求处理和响应
+
+### 1.4 核心组件
+
+#### 1.4.1 Service层
+
+Service层是系统的核心业务层，包含了大量的Service类，主要特点：
+
+- 大多数Service类实现了IEntityService、QueryService和VoableService三个接口
+- 使用@CacheConfig、@Cacheable、@CacheEvict等注解进行缓存管理
+- 负责实体类和VO类之间的转换
+- 被WebSocket服务通过反射机制动态调用
+
+#### 1.4.2 WebSocket服务
+
+WebSocket服务是系统的通信核心，主要组件：
+
+- WebSocketServerHandler：负责WebSocket会话管理
+- WebSocketServerTaskManager：负责任务调度
+- WebSocketServerCallbackManager：负责处理客户端消息并调用相应的Service方法
+
+#### 1.4.3 实体类和VO类
+
+- 实体类（Model）：与数据库表一一对应，使用JPA注解映射
+- VO类（View Object）：用于前端展示和WebSocket通信，包含简化的数据结构
+- 实体类通常实现Voable接口，提供toVo方法将自身转换为VO对象
+
+## 2. 需求理解确认
+
+### 2.1 原始需求
+
+原始需求：根据任务文档（Server模块Service缓存调整为Vo对象），执行任务1。
+
+### 2.2 任务文档需求
+
+根据任务文档，任务1的具体需求是：
+
+- 分析现有Service类结构和依赖关系
+- 输出Service类结构分析报告
+- 绘制依赖关系图
+- 分析与其他组件的依赖关系
+- 特别关注WebSocketServerCallbackManager与IEntityService接口的交互逻辑
+- 记录IEntityService、QueryService、VoableService泛型参数
+- 记录特殊方法和缓存配置
+
+### 2.3 边界确认
+
+- **任务范围**：仅限于Server模块中注解了@CacheConfig的Service类
+- **输入**：项目源代码、任务文档
+- **输出**：Service类结构分析报告、ALIGNMENT文档、CONSENSUS文档、DESIGN文档、TASK文档
+- **排除项**：不涉及client模块和common模块的修改
+- **时间约束**：按照6A工作流的阶段划分逐步执行
+
+## 3. 智能决策策略
+
+### 3.1 歧义识别
+
+1. **缓存调整为Vo对象的具体含义**：需要进一步明确是将缓存的键还是值调整为Vo对象
+   - 决策：根据任务文档的上下文，应该是指将缓存的值从实体对象调整为Vo对象
+
+2. **IEntityService接口中getById方法不能使用@Cacheable注解的原因**：需要明确是所有情况还是特定情况
+   - 决策：根据分析，是当实体类有关联实体时不能使用@Cacheable注解
+
+3. **WebSocketServerCallbackManager如何动态识别和调用不同Service的方法**：需要明确具体的实现机制
+   - 决策：通过反射机制分析Service类的接口、父类和方法参数来确定实体类型
+
+### 3.2 结构化问题清单
+
+1. 哪些Service类同时实现了IEntityService、QueryService和VoableService三个接口？
+2. WebSocketServerCallbackManager如何处理不同类型的Service方法调用？
+3. 当前系统的缓存策略有哪些特点和不足？
+4. 实体类和VO类之间的转换机制是否统一？
+5. 如何确保缓存调整后不影响系统的正常运行？
+
+## 4. 疑问澄清
+
+1. **缓存调整的具体目标**：是完全替换实体对象缓存为Vo对象缓存，还是新增Vo对象缓存？
+   - 假设：根据任务名称，应该是将现有的实体对象缓存调整为Vo对象缓存
+
+2. **缓存键的设计**：是否需要统一缓存键的命名规则？
+   - 假设：是的，统一的缓存键命名规则有助于提高系统的可维护性
+
+3. **多接口实现的泛型参数**：如何确保Service类实现多个接口时泛型参数的一致性？
+   - 假设：需要制定统一的规范，确保泛型参数的使用一致
+
+4. **WebSocket通信的兼容性**：缓存调整后是否需要修改WebSocket通信的逻辑？
+   - 假设：可能需要修改WebSocketServerCallbackManager中处理缓存的逻辑，以确保兼容性
+
+5. **测试策略**：如何验证缓存调整的正确性和性能？
+   - 假设：需要编写单元测试和集成测试，测试缓存的读写、清理等操作
+
+## 5. 项目特性规范
+
+### 5.1 文件命名规范
+
+- 分析报告文件：`ANALYSIS_service_class_structure.md`
+- ALIGNMENT文档：`ALIGNMENT_server_service_cache_vo.md`
+- CONSENSUS文档：`CONSENSUS_server_service_cache_vo.md`
+- DESIGN文档：`DESIGN_server_service_cache_vo.md`
+- TASK文档：`TASK_server_service_cache_vo.md`
+
+### 5.2 文档格式规范
+
+- 所有文档使用Markdown格式
+- 文档结构清晰，包含标题、小标题和列表
+- 使用代码块展示代码示例
+- 使用mermaid绘制架构图和依赖关系图
+
+### 5.3 代码规范
+
+- 遵循项目现有的代码规范
+- 使用Lombok注解简化代码
+- 类和方法应有适当的JavaDoc注释
+- 缓存注解的使用应符合项目规范
+
+## 6. 下一步计划
+
+1. 完成ALIGNMENT文档
+2. 创建CONSENSUS文档，确认所有不确定性
+3. 创建DESIGN文档，设计系统架构和接口规范
+4. 创建TASK文档，拆分原子任务
+5. 按计划执行原子任务