forked from xiongyuxing/tiku-backend.net
33 lines
2.2 KiB
Markdown
33 lines
2.2 KiB
Markdown
# ADR 0001：以 .NET + PostgreSQL 作为唯一目标后端
|
||
|
||
- 状态：已接受
|
||
- 日期：2026-07-27
|
||
|
||
## 背景
|
||
|
||
项目已有一套 NestJS 后端，数据库、认证和存储与 Supabase 的部署及规则耦合较深。新的 ASP.NET Core 后端已经形成完整解决方案、EF Core 模型、迁移链和大量业务 API。前后端尚未进入正式开发，当前仍处于可以直接收敛技术路线的窗口。
|
||
|
||
## 决策
|
||
|
||
1. 本仓库是题库 SaaS 唯一继续演进的后端。
|
||
2. 旧 NestJS 仓库冻结为业务行为、接口契约和数据迁移参考；除迁移阻断问题外，不再承接新功能。
|
||
3. EF Core Migration 是普通数据库结构变更的唯一权威历史。生产环境通过 `Tiku.DbMigrator` 显式执行经审查的迁移，API 不在启动时自动同步结构。
|
||
4. 应用只依赖标准 PostgreSQL 能力和 Npgsql，不再以 Supabase 作为运行时依赖或托管目标。
|
||
5. 身份、对象存储、短信、支付和通知通过 Application 层接口隔离供应商，并通过租户级 `TenantExternalProvider` + `TenantSecret` 配置；不建设 Supabase Auth/Storage 兼容层。
|
||
6. Yudao 不作为运行时依赖，只参考其 RBAC、租户套餐、审计和后台产品设计。
|
||
7. 新功能按完整领域闭环迁移和验收，不以 Controller 或 endpoint 数量作为完成标准。
|
||
|
||
## 迁移边界
|
||
|
||
- 认证和授权由 ASP.NET Core、JWT、数据库 Session 和应用权限策略负责。
|
||
- 多租户隔离由请求租户上下文、EF 查询/写入防护、数据库约束和真实 PostgreSQL 测试共同负责。
|
||
- 普通表、列、索引、约束由 EF Core Migration 管理；确有必要的 PostgreSQL 专用 SQL 可以包含在 Migration 中并接受审查。
|
||
- 旧 OpenAPI 用于发现能力缺口，不要求新接口逐字兼容。任何主动不兼容都必须在迁移清单中记录决定和替代接口。
|
||
|
||
## 结果
|
||
|
||
- 不再建设长期双后端或双写链路。
|
||
- 不再保留 Supabase 作为认证、存储或数据库运行时备选目标。
|
||
- 更换 PostgreSQL 托管商或外部服务供应商不要求重写业务代码。
|
||
- 后续开发先补真实 PostgreSQL 测试、强制租户边界、生产配置 fail-fast 和敏感配置加密，再扩展业务模块。
|