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
```typescript
// 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>
```

#### 使用示例
```typescript
// 重构前（重复代码）
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错误
- [ ] 性能不劣化（启动时间、内存占用）