frontend/ARCHITECTURE_REFACTOR_PLAN.md

架构修复方案文档

1. 重构目标

1.1 核心原则

• 单一职责：每个模块只负责一个明确的功能
• 依赖倒置：高层模块不依赖低层模块，都依赖抽象
• 开闭原则：对扩展开放，对修改关闭

1.2 目标架构

src/
├── core/                    # 核心业务逻辑（框架无关）
│   ├── entities/           # 业务实体
│   ├── repositories/       # 仓库接口
│   └── usecases/          # 业务用例
├── data/                   # 数据层
│   ├── datasources/       # 数据源实现（API、DB、Cache）
│   ├── repositories/      # 仓库实现
│   └── mappers/          # 数据映射
├── presentation/          # 表现层
│   ├── components/       # UI组件
│   ├── screens/         # 屏幕组件
│   ├── stores/          # 状态管理
│   └── hooks/           # 自定义hooks
└── infrastructure/      # 基础设施
    ├── navigation/      # 导航
    ├── theme/          # 主题
    └── services/       # 外部服务

2. 具体修复方案

2.1 messageManager.ts 重构方案

现状问题

• 1500+行，上帝对象
• 混合了 WebSocket、数据库、状态管理、UI通知
• 与SQLite深度耦合

目标结构

src/data/
├── datasources/
│   ├── WebSocketClient.ts      # WebSocket连接管理
│   └── MessageDataSource.ts    # 消息数据源
├── repositories/
│   └── MessageRepository.ts    # 消息仓库实现
└── mappers/
    └── MessageMapper.ts        # 消息数据映射

src/core/
├── entities/
│   └── Message.ts              # 消息实体
├── repositories/
│   └── IMessageRepository.ts   # 仓库接口
└── usecases/
    ├── ProcessMessageUseCase.ts
    ├── SyncMessagesUseCase.ts
    └── UpdateReadReceiptUseCase.ts

src/presentation/stores/
└── messageStore.ts             # 简化的消息状态管理

重构步骤

1. 提取 WebSocketClient - 纯连接管理
2. 创建 MessageRepository - 数据访问抽象
3. 创建 UseCases - 业务逻辑
4. 重写 messageStore - 仅负责UI状态
5. 删除旧的 messageManager.ts

2.2 乐观更新工具函数方案

现状问题

• userStore.ts 中重复6+次相同模式
• 代码冗余，难以维护

目标API

// utils/optimisticUpdate.ts
export interface OptimisticUpdateOptions<T, R> {
  store: StoreApi<any>;
  getCurrentState: () => T;
  optimisticUpdate: (current: T) => T;
  apiCall: () => Promise<R>;
  onSuccess?: (result: R, current: T) => T;
  onError?: (error: any, original: T) => void;
}

export async function optimisticUpdate<T, R>(
  options: OptimisticUpdateOptions<T, R>
): Promise<R>

使用示例

// 重构前（重复代码）
set(state => ({ posts: updatedPosts }));
try {
  const result = await postService.like(postId);
  // ...
} catch (error) {
  set(state => ({ posts: originalPosts }));
}

// 重构后（简洁）
await optimisticUpdate({
  store,
  getCurrentState: () => store.getState().posts,
  optimisticUpdate: (posts) => updatePostLikes(posts, postId, true),
  apiCall: () => postService.like(postId),
  onSuccess: (result, posts) => updatePostWithServerData(posts, result),
});

2.3 useResponsive.ts 拆分方案

现状问题

• 485行，43个导出
• 功能混杂：断点检测、响应式值计算、平台检测

目标结构

src/presentation/hooks/responsive/
├── useBreakpoint.ts           # 断点检测
├── useResponsiveValue.ts      # 响应式值映射
├── useOrientation.ts          # 方向检测
├── usePlatform.ts            # 平台检测
├── useScreenSize.ts          # 屏幕尺寸
└── index.ts                  # 统一导出

各Hook职责

• useBreakpoint: 返回当前断点 (mobile/tablet/desktop/wide)
• useResponsiveValue: 根据断点返回不同值
• useOrientation: 返回 portrait/landscape
• usePlatform: 返回 ios/android/web
• useScreenSize: 返回 width/height

2.4 MainNavigator 解耦方案

现状问题

• 1118行，直接依赖store
• 混合了导航配置和业务逻辑

目标结构

src/infrastructure/navigation/
├── MainNavigator.tsx         # 简化后的导航器
├── AuthNavigator.tsx         # 认证导航
├── TabNavigator.tsx          # 标签导航
├── navigationService.ts      # 导航服务（解耦层）
├── navigationTypes.ts        # 类型定义
└── hooks/
    └── useNavigationState.ts # 导航状态hook

解耦策略

1. 创建 NavigationService - 提供导航操作的抽象
2. Store通过NavigationService触发导航，而非直接操作
3. MainNavigator只负责渲染，不处理业务逻辑

2.5 Repository 层创建方案

现状问题

• 服务层直接操作数据库
• 没有明确的数据访问边界

目标结构

src/data/repositories/
├── MessageRepository.ts      # 消息数据访问
├── PostRepository.ts        # 帖子数据访问
├── UserRepository.ts        # 用户数据访问
└── interfaces/
    ├── IMessageRepository.ts
    ├── IPostRepository.ts
    └── IUserRepository.ts

职责划分

• Repository: 数据访问抽象，定义接口
• DataSource: 具体数据源实现（API、SQLite、Cache）
• Service: 业务逻辑编排，使用Repository

3. 实施计划

阶段1：基础设施（第1-2天）

• 创建目录结构
• 实现乐观更新工具函数
• 拆分 useResponsive hooks

阶段2：数据层重构（第3-5天）

• 创建 Repository 接口和实现
• 创建 DataSource 层
• 迁移数据库操作到 Repository

阶段3：核心业务重构（第6-10天）

• 重构 messageManager → UseCases + Store
• 创建 WebSocketClient
• 实现消息同步逻辑

阶段4：表现层重构（第11-12天）

• 解耦 MainNavigator
• 重构 userStore 使用乐观更新工具
• 更新所有屏幕组件

阶段5：测试与优化（第13-14天）

• 单元测试
• 集成测试
• 性能优化

4. 风险与应对

风险	影响	应对措施
重构引入bug	高	每个模块重构后必须测试，保持API兼容
开发时间超期	中	分阶段交付，优先核心功能
团队成员不熟悉新架构	中	编写详细文档，代码审查
性能下降	低	添加性能监控，及时优化

5. 验收标准

• messageManager.ts 被删除，功能拆分到多个小模块
• userStore.ts 中无重复乐观更新代码
• useResponsive.ts 拆分为5+个专注hook
• MainNavigator.tsx 行数 < 300
• 所有单元测试通过
• 无TypeScript错误
• 性能不劣化（启动时间、内存占用）