AIclinicalresearch/docs/00-系统总体设计/01-系统架构分层设计.md

# 系统架构分层设计

> **文档版本：** v1.0  
> **创建日期：** 2025-11-06  
> **最后更新：** 2025-11-06  
> **文档状态：** 架构设计中  
> **作者：** 技术架构师

---

## 📋 文档说明

本文档是壹证循AI科研平台的**核心架构设计文档**，定义了：
1. **总体架构**：平台级的基础设施和通用能力
2. **业务模块**：各个独立的产品模块
3. **可复用能力**：跨模块共享的技术能力
4. **模块独立性**：如何支持模块独立部署和销售

**核心设计原则：**
- ✅ **总体与模块分离**：平台基础设施与业务模块清晰分层
- ✅ **能力可复用**：通用能力在平台层统一提供
- ✅ **模块可独立**：任何模块都可以独立部署和销售
- ✅ **架构可演进**：从单体到微服务平滑演进

---

## 🏗️ 架构分层总览

### 三层架构

```
┌─────────────────────────────────────────────────────────────┐
│                      业务模块层（Product Layer）                │
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐   │
│  │  AIA   │ │  ASL   │ │  PKB   │ │  DC    │ │  SSA   │ … │
│  │智能问答│ │智能文献│ │知识库  │ │数据清洗│ │智能统计│   │
│  └────────┘ └────────┘ └────────┘ └────────┘ └────────┘   │
└─────────────────────────────────────────────────────────────┘
                              ↓ 依赖
┌─────────────────────────────────────────────────────────────┐
│                    通用能力层（Capability Layer）             │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐          │
│  │LLM网关  │ │文档处理 │ │RAG引擎  │ │数据ETL  │ …        │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘          │
└─────────────────────────────────────────────────────────────┘
                              ↓ 依赖
┌─────────────────────────────────────────────────────────────┐
│                    平台基础层（Platform Layer）               │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐          │
│  │用户权限 │ │存储服务 │ │通知服务 │ │监控日志 │ …        │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘          │
└─────────────────────────────────────────────────────────────┘
```

---

## 📐 第一层：平台基础层（Platform Layer）

### 定义

**平台基础层是所有业务模块的地基，提供通用的基础设施能力。**

### 核心特征

- ✅ **全局唯一**：整个平台只有一套
- ✅ **业务无关**：不涉及具体业务逻辑
- ✅ **强依赖性**：所有业务模块都必须依赖
- ✅ **稳定性高**：很少变动

### 包含的模块

#### 1. 用户与权限中心（UAM）

**职责：**
- 用户注册、登录、认证（JWT）
- 用户信息管理
- 角色与权限管理（RBAC）
- 多租户管理（SaaS版）
- Feature Flag控制（版本权限）

**数据表：**
```typescript
// 平台层Schema: platform_schema
- users               // 用户基础信息
- roles               // 角色定义
- permissions         // 权限定义
- user_roles          // 用户-角色关联
- role_permissions    // 角色-权限关联
- tenants             // 租户（SaaS多租户）
- feature_flags       // Feature Flag配置
```

**API示例：**
```
POST   /api/auth/register          // 注册
POST   /api/auth/login             // 登录
GET    /api/users/me               // 获取当前用户
PUT    /api/users/me               // 更新用户信息
GET    /api/users/permissions      // 获取用户权限
GET    /api/users/feature-flags    // 获取用户Feature Flag
```

---

#### 2. 存储服务（Storage Service）

**职责：**
- 文件上传、下载、删除
- 支持本地开发和云端部署无缝切换
- 统一的存储接口，业务模块无需关心底层实现

**技术方案（云原生架构 - 适配器模式）：**

```typescript
// 统一接口定义
interface StorageAdapter {
  upload(key: string, buffer: Buffer): Promise<string>
  download(key: string): Promise<Buffer>
  delete(key: string): Promise<void>
  getUrl(key: string): string
}

// 本地开发：LocalAdapter
class LocalAdapter implements StorageAdapter {
  private uploadDir = './uploads'
  // 实现：保存到本地文件系统
}

// 生产环境：OSSAdapter
class OSSAdapter implements StorageAdapter {
  private client: OSS
  // 实现：上传到阿里云OSS
}

// 工厂类：自动切换
class StorageFactory {
  static create(): StorageAdapter {
    const type = process.env.STORAGE_TYPE || 'local'
    return type === 'oss' ? new OSSAdapter() : new LocalAdapter()
  }
}

// 业务模块使用
export const storage = StorageFactory.create()
```

**部署架构：**

| 环境 | 适配器 | 配置 | 说明 |
|------|--------|------|------|
| 本地开发 | LocalAdapter | `STORAGE_TYPE=local` | 文件存储到 `./uploads/` |
| 云端SaaS | OSSAdapter | `STORAGE_TYPE=oss` | 文件存储到阿里云OSS |
| 私有化部署 | LocalAdapter | `STORAGE_TYPE=local` | 文件存储到服务器磁盘 |
| 单机版 | LocalAdapter | `STORAGE_TYPE=local` | 文件存储到用户本地 |

**业务模块使用：**

```typescript
// 所有业务模块（ASL/AIA/PKB等）统一使用
import { storage } from '@/common/storage'

// 上传（不关心本地还是OSS）
const url = await storage.upload('literature/123.pdf', pdfBuffer)
```

**优势：**
- ✅ 业务代码零改动切换环境
- ✅ 本地开发无需云服务
- ✅ 生产环境一键切换
- ✅ 所有模块复用同一套代码
- ✅ 支持PRD定义的4种部署形态

**实施状态：** ✅ 2025-11-17 完成（LocalAdapter + OSSAdapter预留）

**实施文档：**
- [平台基础设施规划](../09-架构实施/04-平台基础设施规划.md)
- [backend/src/common/README.md](../../backend/src/common/README.md)
- [平台基础设施实施完成报告](../08-项目管理/03-每周计划/2025-11-17-平台基础设施实施完成报告.md)

---

#### 2.1. 日志系统（Logging Service）⭐ 2025-11-17 新增

**职责：**
- 结构化日志输出（JSON格式）
- 支持本地开发和云端部署
- 集成阿里云SLS（生产环境）

**实现方式：**

```typescript
// Winston配置
import { logger } from '@/common/logging'

// 基础日志
logger.info('User logged in', { userId: 123 })
logger.error('Database error', { error: err.message })

// 带上下文的日志
const aslLogger = logger.child({ module: 'ASL', projectId: 456 })
aslLogger.info('Screening started', { count: 100 })
```

**输出格式：**
- 本地开发：彩色可读格式
- 生产环境：JSON格式（便于SLS解析）

**实施状态：** ✅ 2025-11-17 完成（需安装winston依赖）

---

#### 2.2. 缓存服务（Cache Service）⭐ 2025-11-17 新增

**职责：**
- LLM响应缓存（减少API调用成本）
- 数据库查询结果缓存
- Session缓存

**实现方式：**

```typescript
// 适配器模式：MemoryCacheAdapter | RedisCacheAdapter
import { cache } from '@/common/cache'

// 缓存LLM响应（1小时）
const cacheKey = `llm:${model}:${hash(prompt)}`
await cache.set(cacheKey, response, 60 * 60)
const cached = await cache.get(cacheKey)
```

**环境切换：**
- 本地开发：`CACHE_TYPE=memory`
- 云端部署：`CACHE_TYPE=redis`

**实施状态：** ✅ 2025-11-17 完成（MemoryCache + RedisCache预留）

---

#### 2.3. 异步任务（Job Queue）⭐ 2025-11-17 新增

**职责：**
- 长时间任务异步处理（避免Serverless超时）
- 任务进度查询
- 支持任务重试和失败处理

**实现方式：**

```typescript
import { jobQueue } from '@/common/jobs'

// 创建任务（立即返回）
const job = await jobQueue.push('asl:screening', {
  projectId: 123,
  literatureIds: [1, 2, 3]
})

// 返回任务ID给前端
res.send({ jobId: job.id })

// 前端轮询任务状态
const status = await jobQueue.getJob(job.id)
// { status: 'processing', progress: 45 }
```

**环境切换：**
- 本地开发：`QUEUE_TYPE=memory`
- 云端部署：`QUEUE_TYPE=database`

**实施状态：** ✅ 2025-11-17 完成（MemoryQueue + DatabaseQueue预留）

---

#### 2.4. 健康检查（Health Check）⭐ 2025-11-17 新增

**职责：**
- SAE存活检查（Liveness Probe）
- SAE就绪检查（Readiness Probe）
- 数据库连接监控

**端点：**
- `GET /health/liveness` - 简单响应
- `GET /health/readiness` - 检查数据库、内存等
- `GET /health` - 详细健康信息（开发用）

**实施状态：** ✅ 2025-11-17 完成

---

#### 2.5. 监控指标（Monitoring）⭐ 2025-11-17 新增

**职责：**
- 数据库连接数监控（带告警）
- 内存使用监控（带告警）
- API响应时间监控
- LLM调用统计

**使用方式：**

```typescript
import { Metrics } from '@/common/monitoring'

// 记录数据库连接数（带告警）
await Metrics.recordDBConnectionCount()

// 记录API响应时间
Metrics.recordAPIResponseTime('GET', '/api/projects', 200, 150)

// 记录LLM调用
Metrics.recordLLMCall('deepseek', 'chat', 1500, true, { total: 300 })
```

**实施状态：** ✅ 2025-11-17 完成

---

#### 2.6. 数据库连接池（Connection Pool）⭐ 2025-11-17 新增

**职责：**
- 防止Serverless扩容导致连接数超限
- 优雅关闭连接（SIGTERM信号处理）
- 连接数监控

**配置：**

```bash
# 动态连接限制计算
# connectionLimit = (RDS_MAX_CONNECTIONS / MAX_INSTANCES) - 预留

DB_MAX_CONNECTIONS=400  # RDS最大连接数
MAX_INSTANCES=20        # SAE最大实例数
# 每实例推荐：18个连接
```

**实施状态：** ✅ 2025-11-17 完成

---

#### 3. 通知服务（Notification Service）

**职责：**
- 站内消息
- 邮件通知
- WebSocket实时推送

**数据表：**
```typescript
// 平台层Schema: platform_schema
- notifications       // 通知记录
- notification_templates // 通知模板
```

**API示例：**
```
GET    /api/notifications          // 获取通知列表
POST   /api/notifications/:id/read // 标记已读
```

---

#### 4. 监控与日志（Monitoring & Logging）

**职责：**
- 操作日志
- 错误日志
- 性能监控
- 审计日志（合规要求）

**数据表：**
```typescript
// 平台层Schema: platform_schema
- admin_logs          // 管理员操作日志
- error_logs          // 错误日志
- audit_logs          // 审计日志（合规）
```

---

#### 5. 系统配置（System Config）

**职责：**
- 系统级配置管理
- 多环境配置（开发、测试、生产）
- 动态配置更新

**数据表：**
```typescript
// 平台层Schema: platform_schema
- system_configs      // 系统配置
```

---

## 🔧 第二层：通用能力层（Capability Layer）

### 定义

**通用能力层是跨业务模块共享的核心技术能力，是业务逻辑的基础。**

### 核心特征

- ✅ **可复用**：多个业务模块共享
- ✅ **业务相关**：包含领域知识
- ✅ **独立部署**：可以独立为微服务
- ✅ **高内聚**：每个能力职责单一

### 包含的能力

#### 1. LLM大模型网关（LLM Gateway）⭐⭐⭐⭐⭐ **核心**

**职责：**
- 统一管理所有LLM调用
- 根据用户版本动态切换模型
- 成本控制与限流
- Token计数与计费

**核心价值：**
```
这是商业模式的技术保障：
- 基础版：只能用DeepSeek-V3（便宜）
- 高级版：可用DeepSeek + Qwen3
- 旗舰版：可用DeepSeek + Qwen3 + Qwen-Long + Claude

成本控制：
- 统一监控所有LLM API调用
- 超出配额自动限流
- 按版本计费
```

**技术架构：**
```typescript
// LLM Gateway统一入口
interface LLMGateway {
  // 调用LLM
  chat(params: {
    userId: string;
    modelType?: 'deepseek-v3' | 'qwen3' | 'qwen-long' | 'claude';
    messages: Message[];
    stream?: boolean;
  }): Promise<ChatResponse>;
  
  // 根据用户版本选择模型
  selectModel(userId: string, preferredModel?: string): string;
  
  // 检查配额
  checkQuota(userId: string): Promise<{ allowed: boolean; remaining: number }>;
  
  // Token计数
  countTokens(text: string): number;
}
```

**数据表：**
```typescript
// 通用能力Schema: capability_schema
- llm_usage_logs      // LLM使用日志
- llm_quotas          // 用户配额
```

**为什么是通用能力？**
- ✅ AIA模块需要（AI智能问答）
- ✅ ASL模块需要（AI智能文献筛选）
- ✅ PKB模块需要（知识库RAG问答）
- ✅ DC模块需要（数据清洗NER提取）
- ✅ 审稿模块需要（稿件审查）

**所有模块都依赖LLM Gateway！**

---

#### 2. 文档处理引擎（Document Processing Engine）⭐⭐⭐⭐⭐ **核心**

**职责：**
- 多格式文档提取（PDF/Docx/Txt/Excel）
- 文本清洗与预处理
- OCR处理
- 表格提取

**技术架构：**
```typescript
// Python微服务（已实现）
interface DocumentProcessor {
  // 提取文本
  extract(file: File, method: 'pymupdf' | 'nougat' | 'mammoth'): Promise<{
    text: string;
    metadata: {
      charCount: number;
      language: string;
      quality: number;
    };
  }>;
  
  // 提取表格
  extractTables(file: File): Promise<Table[]>;
  
  // OCR处理
  ocr(image: Buffer): Promise<string>;
}
```

**为什么是通用能力？**
- ✅ ASL模块需要（文献PDF提取）
- ✅ PKB模块需要（知识库文档上传）
- ✅ DC模块需要（Excel/Docx数据导入）
- ✅ 审稿模块需要（稿件文档提取）

**至少4个模块依赖文档处理引擎！**

---

#### 3. RAG引擎（RAG Engine）⭐⭐⭐⭐ **核心**

**职责：**
- 向量化存储（Embedding）
- 语义检索（Semantic Search）
- 检索增强生成（RAG）
- Rerank重排序

**技术架构：**
```typescript
// 基于Dify或自建向量数据库
interface RAGEngine {
  // 创建知识库
  createDataset(name: string, description?: string): Promise<string>;
  
  // 上传文档
  uploadDocument(datasetId: string, file: File): Promise<string>;
  
  // 语义检索
  search(datasetId: string, query: string, topK?: number): Promise<SearchResult[]>;
  
  // RAG问答
  chatWithRAG(datasetId: string, query: string, history?: Message[]): Promise<string>;
}
```

**为什么是通用能力？**
- ✅ PKB模块需要（个人知识库问答）
- ✅ ASL模块需要（文献内容检索）
- ✅ AIA模块需要（@知识库问答）

**至少3个模块依赖RAG引擎！**

---

#### 4. 数据ETL引擎（Data ETL Engine）⭐⭐⭐ **中等**

**职责：**
- Excel多表JOIN
- 数据清洗
- 数据转换
- 数据验证

**技术架构：**
```python
# Python微服务（基于Polars）
class ETLEngine:
    # 读取多个Excel
    def read_excel(self, files: List[File]) -> List[DataFrame]:
        pass
    
    # JOIN操作
    def join(self, dfs: List[DataFrame], keys: List[str]) -> DataFrame:
        pass
    
    # 数据清洗
    def clean(self, df: DataFrame, rules: Dict) -> DataFrame:
        pass
    
    # 导出
    def export(self, df: DataFrame, format: str) -> bytes:
        pass
```

**为什么是通用能力？**
- ✅ DC模块需要（数据清洗整理）
- ✅ SSA模块需要（统计分析数据预处理）

**至少2个模块依赖ETL引擎！**

---

#### 5. 医学NLP引擎（Medical NLP Engine）⭐⭐⭐ **中等**

**职责：**
- 医学实体识别（NER）
- 医学术语标准化
- 疾病/药物识别

**技术架构：**
```python
# Python微服务（基于spaCy + 医学模型）
class MedicalNLP:
    # 实体识别
    def extract_entities(self, text: str) -> List[Entity]:
        pass
    
    # 术语标准化
    def normalize(self, term: str) -> str:
        pass
    
    # 疾病识别
    def extract_diseases(self, text: str) -> List[str]:
        pass
```

**为什么是通用能力？**
- ✅ DC模块需要（病例数据NER提取）
- ✅ ASL模块可能需要（文献关键词提取）

---

## 🎨 第三层：业务模块层（Product Layer）

### 定义

**业务模块层是面向用户的产品功能，每个模块都是独立的产品单元。**

### 核心特征

- ✅ **独立部署**：可以单独打包部署
- ✅ **独立销售**：可以单独售卖
- ✅ **低耦合**：模块间不直接依赖
- ✅ **高内聚**：模块内功能完整

### 模块清单

| 模块代号 | 模块名称 | 核心功能 | 商业价值 | 技术栈 | 依赖的通用能力 |
|---------|---------|---------|---------|-------|--------------|
| **AIA** | AI智能问答 | 10+智能体 | ⭐⭐⭐⭐ 差异化 | Node.js + Dify | LLM网关、RAG引擎 |
| **ASL** | AI智能文献 | 文献筛选、提取 | ⭐⭐⭐⭐⭐ 核心 | Node.js + Python | LLM网关、文档处理、RAG引擎 |
| **PKB** | 个人知识库 | RAG问答 | ⭐⭐⭐ 辅助 | Node.js + Dify | LLM网关、文档处理、RAG引擎 |
| **DC** | 数据清洗整理 | 自动ETL + NER | ⭐⭐⭐⭐⭐ 核心 | Node.js + Python | LLM网关、文档处理、ETL引擎、医学NLP |
| **SSA** | 智能统计分析 | 3条分析路径 | ⭐⭐⭐⭐⭐ 刚需 | Node.js + R | 文档处理、ETL引擎 |
| **ST** | 统计分析工具 | 100+小工具 | ⭐⭐⭐⭐ 高频 | Node.js + R | 文档处理 |
| **RVW** | 稿件审查系统 | 方法学评估 | ⭐⭐⭐⭐ 独立 | Node.js + Python | LLM网关、文档处理 |

---

### 业务模块详述

#### 1. AIA - AI智能问答模块 ✅ **已完成**

**当前状态：**
- ✅ 10个智能体已实现
- ✅ 多轮对话
- ✅ 流式输出
- ✅ 模型切换
- ✅ @知识库问答

**数据Schema：**
```typescript
// 业务模块Schema: aia_schema
- projects            // 项目
- conversations       // 对话
- messages            // 消息
- agents_config       // 智能体配置
```

**独立部署能力：**
- ✅ 前端：可独立打包
- ✅ 后端：可独立运行（依赖LLM网关、RAG引擎）
- ✅ 数据库：独立Schema
- ⚠️ 需要：平台层（用户认证）

---

#### 2. ASL - AI智能文献模块 ⏳ **规划中**

**核心功能：**
1. 标题摘要初筛（双模型AI判断）
2. 全文复筛（PDF全文分析）
3. 全文解析与数据提取
4. 数据分析与报告生成
5. 系统评价与Meta分析
6. 文献管理

**数据Schema：**
```typescript
// 业务模块Schema: asl_schema
- literature_projects         // 文献项目
- literature_items            // 文献条目
- pico_configs                // PICO(S)配置
- screening_results           // 筛选结果
- screening_history           // 筛选历史
- extraction_tasks            // 提取任务
- extraction_results          // 提取结果
- meta_analysis_tasks         // Meta分析任务
```

**独立部署能力：**
- ✅ 前端：独立React应用
- ✅ 后端：独立Node.js服务
- ✅ 数据库：独立Schema
- ✅ 依赖：LLM网关、文档处理、RAG引擎

**独立销售价值：⭐⭐⭐⭐⭐ 非常高！**
- 可以作为独立产品"AI文献筛选系统"售卖
- 目标客户：系统评价研究者、循证医学中心

---

#### 3. PKB - 个人知识库模块 ✅ **已完成**

**当前状态：**
- ✅ 知识库CRUD
- ✅ 文档上传
- ✅ RAG问答
- ✅ @知识库引用

**数据Schema：**
```typescript
// 业务模块Schema: pkb_schema
- knowledge_bases     // 知识库
- documents           // 文档
```

**独立部署能力：**
- ✅ 前端：可独立打包
- ✅ 后端：可独立运行
- ✅ 数据库：独立Schema
- ✅ 依赖：LLM网关、文档处理、RAG引擎

---

#### 4. DC - 数据清洗整理模块 ⏳ **规划中**

**核心功能：**
1. 多Excel文件导入
2. 自动JOIN和清洗
3. 医学NER实体提取
4. 数据质量报告
5. 导出标准化数据

**数据Schema：**
```typescript
// 业务模块Schema: dc_schema
- dc_projects         // 数据清洗项目
- dc_raw_files        // 原始文件
- dc_cleaned_data     // 清洗后数据
- dc_ner_results      // NER提取结果
- dc_quality_reports  // 质量报告
```

**独立部署能力：**
- ✅ 前端：独立React应用
- ✅ 后端：Node.js + Python微服务
- ✅ 数据库：独立Schema（SQLite for 单机版）
- ✅ 依赖：LLM网关、文档处理、ETL引擎、医学NLP

**独立销售价值：⭐⭐⭐⭐⭐ 非常高！**
- 可以作为独立产品"医学数据清洗工具"售卖
- 目标客户：临床科室、数据管理员

---

#### 5. SSA - 智能统计分析模块 ⏳ **规划中**

**核心功能：**
1. 队列研究分析
2. 预测模型构建
3. RCT研究分析
4. 数据质量核查
5. 统计分析报告

**数据Schema：**
```typescript
// 业务模块Schema: ssa_schema
- ssa_projects        // 统计分析项目
- ssa_datasets        // 数据集
- ssa_analysis_tasks  // 分析任务
- ssa_results         // 分析结果
- ssa_reports         // 分析报告
```

**独立部署能力：**
- ✅ 前端：独立React应用
- ✅ 后端：Node.js + R微服务
- ✅ 数据库：独立Schema
- ✅ 依赖：文档处理、ETL引擎

**独立销售价值：⭐⭐⭐⭐⭐ 非常高！**
- 可以作为独立产品"临床统计分析平台"售卖

---

#### 6. ST - 统计分析工具模块 ⏳ **规划中**

**核心功能：**
- 100+小工具（t检验、卡方检验、ROC曲线等）

**数据Schema：**
```typescript
// 业务模块Schema: st_schema
- st_tool_usage       // 工具使用记录
```

**独立部署能力：**
- ✅ 前端：独立React应用
- ✅ 后端：Node.js + R微服务
- ✅ 数据库：独立Schema（可选）
- ✅ 依赖：文档处理

---

#### 7. RVW - 稿件审查系统 ⏳ **规划中（已有核心功能）**

**当前状态：**
- ✅ 文档上传
- ✅ 文本提取
- ✅ 稿约规范性评估（editorial_review）
- ✅ 方法学评估（methodology_review）
- ✅ 综合评分

**未来扩展：**
- ⚠️ 审稿人管理
- ⚠️ 审稿流程管理
- ⚠️ 多轮审稿
- ⚠️ 审稿意见模板

**数据Schema：**
```typescript
// 业务模块Schema: review_schema
- review_tasks        // 审查任务（已有）
// 未来扩展：
- review_journals     // 期刊库
- review_reviewers    // 审稿人
- review_workflows    // 审稿流程
- review_comments     // 审稿意见
```

**独立部署能力：**
- ✅ 前端：独立React应用
- ✅ 后端：独立Node.js服务
- ✅ 数据库：独立Schema
- ✅ 依赖：LLM网关、文档处理

**独立销售价值：⭐⭐⭐⭐⭐ 极高！**
- 可以作为完全独立的产品"AI辅助审稿系统"售卖
- 目标客户：期刊编辑部、出版社、学会
- 商业模式：按期刊订阅，或按稿件数量计费

**为什么审稿系统适合独立？**
1. ✅ **用户群独立**：期刊编辑部 vs 临床医生（完全不同）
2. ✅ **业务逻辑独立**：与其他模块无关联
3. ✅ **部署场景独立**：期刊编辑部有自己的部署需求
4. ✅ **商业模式独立**：可以按期刊订阅

---

## 🔗 模块间关系

### 依赖关系图

```
业务模块层
  ├── AIA (AI智能问答)
  │     └── 依赖：LLM网关、RAG引擎
  │
  ├── ASL (AI智能文献)
  │     └── 依赖：LLM网关、文档处理、RAG引擎
  │
  ├── PKB (个人知识库)
  │     └── 依赖：LLM网关、文档处理、RAG引擎
  │
  ├── DC (数据清洗)
  │     └── 依赖：LLM网关、文档处理、ETL引擎、医学NLP
  │
  ├── SSA (智能统计分析)
  │     └── 依赖：文档处理、ETL引擎
  │
  ├── ST (统计分析工具)
  │     └── 依赖：文档处理
  │
  └── RVW (稿件审查)
        └── 依赖：LLM网关、文档处理

通用能力层
  ├── LLM网关 ⭐ (所有AI模块依赖)
  ├── 文档处理引擎 ⭐ (所有文档模块依赖)
  ├── RAG引擎 (AIA、ASL、PKB依赖)
  ├── ETL引擎 (DC、SSA依赖)
  └── 医学NLP (DC依赖)

平台基础层
  ├── 用户与权限中心 ⭐ (所有模块依赖)
  ├── 存储服务 ⭐ (所有模块依赖)
  ├── 通知服务
  ├── 监控与日志
  └── 系统配置
```

### 关键洞察

**1. LLM网关是核心中枢**
```
依赖LLM网关的模块：
- AIA（AI智能问答）
- ASL（AI智能文献）
- PKB（个人知识库）
- DC（数据清洗）
- RVW（稿件审查）

共计：5个模块 / 7个模块 = 71%

结论：LLM网关必须优先设计和实现！
```

**2. 文档处理引擎使用广泛**
```
依赖文档处理的模块：
- ASL（文献PDF提取）
- PKB（知识库文档）
- DC（Excel/Docx导入）
- SSA（数据导入）
- ST（数据导入）
- RVW（稿件提取）

共计：6个模块 / 7个模块 = 86%

结论：文档处理引擎已实现，需要继续增强！
```

**3. 模块独立性分析**

| 模块 | 独立性 | 原因 |
|------|-------|------|
| **RVW（审稿）** | ⭐⭐⭐⭐⭐ 极高 | 用户群、业务逻辑、部署场景都完全独立 |
| **ASL（文献）** | ⭐⭐⭐⭐⭐ 极高 | 可作为独立产品售卖给系统评价研究者 |
| **DC（数据清洗）** | ⭐⭐⭐⭐⭐ 极高 | 可作为独立产品售卖给数据管理员 |
| **SSA（统计分析）** | ⭐⭐⭐⭐ 高 | 可独立，但与ST模块有协同效应 |
| **ST（分析工具）** | ⭐⭐⭐⭐ 高 | 可独立，但与SSA模块有协同效应 |
| **AIA（AI问答）** | ⭐⭐⭐ 中 | 可独立，但与PKB有较强关联（@知识库） |
| **PKB（知识库）** | ⭐⭐⭐ 中 | 可独立，但与AIA有较强关联（@知识库） |

---

## 💾 数据库架构设计

### Schema隔离策略

**当前问题：**
- ❌ 所有表在同一Schema（public）
- ❌ 未来微服务拆分困难
- ❌ 不支持模块独立部署

**目标架构：**
```sql
-- 平台层Schema
CREATE SCHEMA platform_schema;
  - users
  - roles
  - permissions
  - user_roles
  - role_permissions
  - tenants
  - feature_flags
  - notifications
  - admin_logs
  - system_configs

-- 通用能力Schema
CREATE SCHEMA capability_schema;
  - llm_usage_logs
  - llm_quotas
  - document_processing_logs

-- 业务模块Schema
CREATE SCHEMA aia_schema;        -- AI智能问答
CREATE SCHEMA asl_schema;        -- AI智能文献
CREATE SCHEMA pkb_schema;        -- 个人知识库
CREATE SCHEMA dc_schema;         -- 数据清洗
CREATE SCHEMA ssa_schema;        -- 智能统计分析
CREATE SCHEMA st_schema;         -- 统计分析工具
CREATE SCHEMA review_schema;     -- 稿件审查
```

### 迁移策略

**阶段一：逻辑隔离（当前阶段）**
```
目标：在代码层面按Schema组织，但数据库还是public
方式：Prisma中使用@@map指定表名前缀

例如：
@@map("aia_projects")     // AI问答的项目表
@@map("asl_projects")     // AI文献的项目表
@@map("dc_projects")      // 数据清洗的项目表
```

**阶段二：物理隔离（微服务拆分时）**
```
目标：真正创建独立Schema
方式：
1. 创建新Schema
2. 迁移数据（INSERT INTO new_schema.table SELECT * FROM public.old_table）
3. 更新Prisma Schema
4. 测试验证
```

---

## 🎯 可复用能力总结

### 什么是可复用能力？

**定义：**
- ✅ 被多个模块使用的技术能力
- ✅ 可以独立为服务
- ✅ 有明确的接口定义
- ✅ 职责单一

### 核心可复用能力清单

| 能力 | 使用频率 | 复用模块 | 优先级 | 当前状态 |
|------|---------|---------|--------|---------|
| **LLM网关** | 71% (5/7) | AIA、ASL、PKB、DC、RVW | P0 | ❌ 未实现 |
| **文档处理引擎** | 86% (6/7) | 所有模块 | P0 | ✅ 已实现 |
| **RAG引擎** | 43% (3/7) | AIA、ASL、PKB | P1 | ✅ 已实现（基于Dify） |
| **ETL引擎** | 29% (2/7) | DC、SSA | P2 | ❌ 未实现 |
| **医学NLP** | 14% (1/7) | DC | P2 | ❌ 未实现 |

### 立即行动

**P0能力（必须立即设计）：**
1. ✅ **LLM网关** - 商业模式的基础，5个模块依赖
2. ✅ **文档处理引擎** - 已实现，需要增强（表格提取）

**P1能力（近期设计）：**
3. ✅ **RAG引擎** - 已实现，需要优化
4. ⚠️ **ETL引擎** - DC模块开发时再设计

**P2能力（延后）：**
5. ⚠️ **医学NLP** - DC模块开发时再设计

---

## 🚀 架构演进路径

### 阶段一：模块化单体（当前 - 6个月）

**架构特点：**
```
单一代码库，但严格按模块划分：
backend/
  ├── platform/           # 平台层
  │   ├── auth/
  │   ├── storage/
  │   └── notification/
  ├── capabilities/       # 通用能力层
  │   ├── llm-gateway/
  │   ├── document/
  │   └── rag/
  ├── modules/            # 业务模块层
  │   ├── aia/
  │   ├── asl/
  │   ├── pkb/
  │   ├── dc/
  │   ├── ssa/
  │   ├── st/
  │   └── review/
  └── shared/             # 共享工具

单一数据库，但逻辑隔离（表名前缀）
```

**关键纪律：**
- ✅ 模块间不直接import，只能通过接口调用
- ✅ 每个模块有独立的路由、服务、数据访问层
- ✅ 使用表名前缀（逻辑Schema隔离）

---

### 阶段二：首次拆分（6-18个月）

**触发条件：**
- 有客户要求私有化部署
- 有客户要求单机版
- 需要独立销售某个模块

**拆分策略：**
```
1. 优先拆分RVW（审稿系统）- 最独立
2. 其次拆分DC或ASL - 商业价值高
3. 引入API网关
4. 引入K8s（可选，私有化部署需要）
```

**架构：**
```
API网关 (Kong/Traefik)
  ├── 平台服务 (UAM、Storage)
  ├── LLM网关服务
  ├── 文档处理服务 (Python微服务)
  ├── 审稿模块服务 (独立部署)
  └── 其他模块服务 (暂时仍为单体)
```

---

### 阶段三：全面微服务（18个月+）

**架构：**
```
所有模块独立部署，支持灵活组合和模块化售卖
```

---

## 📊 总结

### 架构分层回答了您的关键问题

**1. 哪些是总体的？**
- ✅ 平台基础层：用户权限、存储、通知、监控、配置

**2. 哪些是通用的技术能力？**
- ✅ 通用能力层：LLM网关、文档处理、RAG引擎、ETL引擎、医学NLP

**3. 哪些是各子模块独立的功能？**
- ✅ 业务模块层：AIA、ASL、PKB、DC、SSA、ST、RVW

**4. 哪些能力是复用的？**
- ✅ LLM网关（5个模块）
- ✅ 文档处理（6个模块）
- ✅ RAG引擎（3个模块）

**5. 哪些可以随时独立成系统？**
- ⭐⭐⭐⭐⭐ **RVW（审稿系统）** - 最适合独立
- ⭐⭐⭐⭐⭐ **ASL（智能文献）** - 商业价值高
- ⭐⭐⭐⭐⭐ **DC（数据清洗）** - 商业价值高

---

**下一步：基于这个架构分层，重新组织文档结构。**