HaHafeng
83e395824b
Deliver the RVW V4.0 journal configuration center across backend, frontend, migration, and docs with zh/en editorial baseline support and tenant-level prompt/template overrides. Unify tenant login to /:tenantCode/login and auto-enable RVW module when tenant type is JOURNAL to prevent post-login access gaps. Made-with: Cursor
117 lines
6.4 KiB
Markdown
117 lines
6.4 KiB
Markdown
# **ADMIN 运营管理端：多业态租户架构演进评估与设计指南**
|
||
|
||
**文档定位：** 针对平台未来面临“医院、药企、期刊”三大业态分化的战略级架构指导文件。
|
||
|
||
**核心主旨：** 摒弃“上帝级”通用租户配置页，走向\*\*“数据底层大一统，前端展现分而治之”\*\*的 SaaS 演进路线。
|
||
|
||
**评估结论：** 强烈建议将“期刊配置中心”在前端作为独立一级菜单和页面独立出来。
|
||
|
||
## **🔍 一、 业务形态分化趋势评估**
|
||
|
||
平台目前服务的三类客户，其核心诉求与配置维度已经发生根本性分化：
|
||
|
||
| 业态类型 | 核心业务模块 | ADMIN 端的配置侧重点 | 运营人员视角 |
|
||
| :---- | :---- | :---- | :---- |
|
||
| **医院 / 科研机构** | IIT (研究项目), DC (数据清洗) | REDCap 数据源打通、CRA 质控规则、伦理审查合规性、患者隐私脱敏级别。 | 偏向于“项目制”与“数据安全”管理。 |
|
||
| **药企 / 申办方** | PKB (企业知识库), AIA (智能体) | 专属知识库的向量化参数、RAG 检索阈值、多智能体协作 Prompt、合规审查界限。 | 偏向于“知识资产”与“AI 能力”调优。 |
|
||
| **医学期刊编辑部** | RVW (智能审稿) | 稿约规范双语基线、方法学/临床评估 Prompt 编排、Handlebars 退修信模板定制。 | 偏向于“审稿流水线”与“千刊千面”排版。 |
|
||
|
||
**评估意见**：如果未来继续在同一个 TenantDetailPage.tsx 里通过 if-else 来堆砌这些表单，前端代码将迅速腐化，且运营人员在配置一家期刊时，可能会被医院的 REDCap 配置项干扰。**前端页面的物理拆分势在必行。**
|
||
|
||
## **🏛️ 二、 核心架构建议：底层统一，表层分治**
|
||
|
||
为了兼顾“开发成本”与“运营体验”，建议采用以下架构模式：
|
||
|
||
### **1\. 底层大一统 (Unified Data Model)**
|
||
|
||
**不能把租户表拆散**（不能建 journal\_tenants, hospital\_tenants）。
|
||
|
||
* **原因**：全平台的统一登录 (SSO)、统一计费 (Quotas)、基础信息 (Logo、名称) 必须保持全局唯一，复用现有的 platform\_schema.tenants。
|
||
* **改造动作**：在 tenants 表中新增一个核心的枚举分类字段 tenant\_type。
|
||
|
||
### **2\. 1对1 扩展表 (1-to-1 Extension Tables)**
|
||
|
||
针对不同业态的独特配置，采用垂直分表的模式，保持主表整洁。
|
||
|
||
* 期刊配置存入 tenant\_rvw\_configs
|
||
* 药企配置存入 tenant\_pkb\_configs (未来)
|
||
* 医院配置存入 tenant\_iit\_configs (未来)
|
||
|
||
### **3\. 前端分治 (Decoupled Frontend Views)**
|
||
|
||
在 ADMIN 端的左侧菜单，明确区分业务管理入口，为特定业态打造沉浸式的配置体验。
|
||
|
||
## **💾 三、 数据库 Schema 调整落地 (Prisma)**
|
||
|
||
基于上述思路，在 MVP 阶段的数据库改造应如下进行：
|
||
|
||
// 1\. 定义租户业态枚举
|
||
enum TenantType {
|
||
CLINICAL // 医院/科研机构 (默认)
|
||
PHARMA // 药企/申办方
|
||
JOURNAL // 医学期刊
|
||
INTERNAL // 内部平台测试
|
||
}
|
||
|
||
// 2\. 改造基础租户表
|
||
model Tenant {
|
||
id String @id @default(uuid())
|
||
code String @unique // slug
|
||
name String
|
||
tenantType TenantType @default(CLINICAL) // 新增：业态分类
|
||
journalLanguage String? // 'ZH' | 'EN' (仅当 type=JOURNAL 时有效)
|
||
|
||
// 关联扩展表
|
||
rvwConfig TenantRvwConfig?
|
||
// pkbConfig TenantPkbConfig? (未来扩展)
|
||
|
||
@@schema("platform\_schema")
|
||
}
|
||
|
||
// 3\. 期刊专属扩展表 (保持不变)
|
||
model TenantRvwConfig {
|
||
id String @id @default(uuid())
|
||
tenantId String @unique
|
||
tenant Tenant @relation(fields: \[tenantId\], references: \[id\])
|
||
// ... Prompt 和 Template 字段
|
||
}
|
||
|
||
## **🖥️ 四、 前端展现独立化设计方案 (ADMIN UI)**
|
||
|
||
在之前的审查中，我曾建议“砍掉独立的期刊配置中心，回归租户详情页”。**在此，基于您的战略预判，我正式推翻该建议，支持您最初的构想：在前端建立独立的《期刊配置中心》。**
|
||
|
||
### **1\. 左侧导航重构**
|
||
|
||
ADMIN 端的导航栏应当按“业态垂直管理”和“平台横向管理”进行划分：
|
||
|
||
▼ 平台横向管理 (横向能力)
|
||
\- 🏢 基础租户池 (所有租户的大盘，仅管理基础信息和计费)
|
||
\- 👥 全局用户与权限
|
||
\- 🎨 Prompt 基础设施
|
||
|
||
▼ 垂直业态中心 (深度定制)
|
||
\- 🏥 临床研究中心配置 (过滤 tenantType=CLINICAL)
|
||
\- 💊 药企知识库配置 (过滤 tenantType=PHARMA)
|
||
\- 📖 期刊 SaaS 配置中心 (过滤 tenantType=JOURNAL)
|
||
|
||
### **2\. “期刊配置中心”的专属交互设计**
|
||
|
||
点击【期刊 SaaS 配置中心】后，前端交互应与普通租户管理区分开：
|
||
|
||
* **列表页 (JournalConfigList)**：
|
||
* 后端 API 依然调用 GET /api/admin/tenants，但前端强制带上参数 ?type=JOURNAL。
|
||
* 列表直接展示期刊专属的列：期刊名称、访问路径(Slug)、语言基线、AI 审查模块开关状态。
|
||
* **新建期刊向导 (Creation Wizard)**：
|
||
* 点击“新增期刊”，不要弹出普通租户那种几十项配置的抽屉。
|
||
* 弹出专属向导：第一步填名称和 Slug，第二步选“中文核心/英文 SCI”，第三步自动为其绑定 RVW 模块权限，一气呵成。
|
||
* **沉浸式配置页 (JournalConfigDetail)**：
|
||
* 左侧是“稿约、方法学、数据、临床” 4 个锚点导航，右侧是您要求的“大文本框 Prompt \+ Handlebars 预览”，完全为期刊实施人员打造，没有任何多余的干扰信息。
|
||
|
||
## **🚀 五、 给 MVP 开发计划的修正建议**
|
||
|
||
您可以直接把这份文档同步给开发团队，并对之前的《MVP 开发计划》做如下调整指示：
|
||
|
||
1. **DB 调整**：必须在 tenants 表新增 tenant\_type (Enum) 字段，以此作为划分业态的唯一真理。
|
||
2. **前端放行**：**恢复执行 FE-1 (新增左侧一级模块) 和 FE-2 (独立的期刊列表页) 任务！** 3\. **接口复用**：前端虽然拆了页面，但后端**不需要**写两套 CRUD。列表查询依然用 /api/admin/tenants?type=JOURNAL，配置更新依然用 /api/admin/tenants/:id/rvw-config。
|
||
|
||
**总结：** 您的这个决定避免了系统在未来半年内演变成一个庞大而混乱的“怪物”。通过**数据层的强内聚**（共享 Tenants 表和 SSO）与**前端页面的强解耦**（独立业务配置中心），平台将具备极强的横向扩展能力！ |