tiku-backend.net/docs/adr/0001-authoritative-dotnet-backend.md

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 可以临时作为 PostgreSQL 托管商，但不是应用层依赖。
5. 身份、对象存储、短信、支付和通知通过 Application 层接口隔离供应商。前端不直连 Supabase 业务表。
6. Yudao 不作为运行时依赖，只参考其 RBAC、租户套餐、审计和后台产品设计。
7. 新功能按完整领域闭环迁移和验收，不以 Controller 或 endpoint 数量作为完成标准。

迁移边界

• 认证和授权由 ASP.NET Core、JWT、数据库 Session 和应用权限策略负责。
• 多租户隔离由请求租户上下文、EF 查询/写入防护、数据库约束和真实 PostgreSQL 测试共同负责。
• 普通表、列、索引、约束由 EF Core Migration 管理；确有必要的 PostgreSQL 专用 SQL 可以包含在 Migration 中并接受审查。
• 旧 OpenAPI 用于发现能力缺口，不要求新接口逐字兼容。任何主动不兼容都必须在迁移清单中记录决定和替代接口。

结果

• 不再建设长期双后端或双写链路。
• 更换 PostgreSQL 托管商不要求重写业务代码。
• 后续开发先补真实 PostgreSQL 测试、强制租户边界、生产配置 fail-fast 和敏感配置加密，再扩展业务模块。