| name | backend-architecture-spec |
| description | 当需要设计后端架构时使用。后端架构设计规范产出，基于业务规模自动评估架构模式、设计服务拆分方案、执行架构审查，内建架构决策记录(ADR)和技术债登记确保决策可追溯。产出经人类审查后，交由backend-architecture-impl生成代码。关键词：架构模式、微服务、单体架构、Serverless、服务设计、DDD、限界上下文、架构审查、技术债、架构决策。 |
| metadata | {"module":"后端架构与开发","sub-module":"后端架构","type":"pipeline","version":"4.0","domain_tags":["电商","SaaS","金融","通用"],"trigger_examples":["选什么架构模式","要不要上微服务","服务怎么拆分","后端代码审查","架构有没有问题"],"interaction_mode":"ai_suggest_human_approve"} |
后端架构设计规范
核心原则
- 适度架构：架构服务于业务，不追求技术先进性
- 演进式架构：从简单开始，按需演进，不一步到位
- 决策可追溯：每个架构决策有明确的理由和上下文，自动生成ADR
- 技术债可见：技术债显式登记和管理，不隐藏
交互模式
🤖→👤 AI建议人类审批
输入
| 输入项 | 类型 | 必填 | 来源 | 说明 |
|---|
| PRD | markdown | 是 | output/pm-design/design-prd/prd.md | 业务领域和流程 |
| PRD结构化数据 | JSON | 是 | output/pm-design/design-prd/prd.json | PRD机器可消费版本，供架构审查对齐检查 |
| 数据模型 | JSON | 是 | output/backend-data-architecture/data-architecture-spec/er_model.json | 数据实体和关系 |
| 业务数据字典 | JSON | ○ | output/backend-data-architecture/data-architecture-spec/data_dictionary.json | 业务数据标准和实体定义，供服务拆分和限界上下文划分参考 |
| API契约 | YAML/JSON | 是 | output/backend-api-design/api-design-spec/openapi.yaml | 接口定义 |
| 业务规模 | JSON | 是 | 用户提供 | 用户量、QPS、数据量、团队规模 |
| 技术约束 | JSON | ○ | 用户提供 | 技术栈、运维能力、预算 |
| 缓存策略 | JSON | ○ | output/backend-data-architecture/data-architecture-spec/cache_strategy.json | 缓存方案 |
执行步骤
Step 1: 架构模式评估与选择
基于多维度评估推荐架构模式（单体/微服务/Serverless），生成系统拓扑图。
阶段卡口：架构模式和演进路线人类已确认
Step 2: 架构决策记录
为每个架构决策生成ADR：
- 决策背景和驱动力
- 备选方案及评估
- 决策结果和理由
- 影响范围和后果
阶段卡口：核心架构决策100%有ADR
Step 3: 服务设计
基于领域驱动设计识别限界上下文，设计服务拆分和通信方案。
阶段卡口：服务间无循环依赖，数据归属明确
Step 4: 后端审查
审查性能、安全、可维护性和可扩展性，输出问题清单和修复建议。
阶段卡口：P0问题=0，架构决策记录完整
Step 5: 技术债登记
识别并登记技术债：
- 从审查问题中提取技术债
- 评估影响范围和修复优先级
- 生成技术债登记册
- 建议修复节奏
阶段卡口：P0技术债=0，技术债登记册已生成
输出
元数据输出：output/backend-architecture/backend-architecture-spec/
输出文件：
- architecture_decision.json — 架构方案+拓扑图
- adr.json — 架构决策记录
- service_design.json — 服务划分+上下文映射
- review_report.json — 审查问题清单+修复建议
- tech_debt_register.json — 技术债登记册
决策规则
| 条件 | 决策 |
|---|
| 团队规模<5人 | 单体架构优先 |
| 团队规模5-20人 | 微服务架构 |
| QPS<1000 | 单体或Serverless |
| 核心业务实体跨子域 | 按限界上下文拆分服务 |
| 审查P0问题>0 | 阻塞发布，必须修复 |
| 技术债影响核心功能 | P0优先级，本迭代修复 |
质量检查
降级策略
| 缺失的上游输入 | 降级方案 | 输出影响 |
|---|
| PRD缺失 | 基于数据模型和API契约推导业务领域 | 服务划分可能不准确 |
| 数据模型缺失 | 无法设计服务 | 输出为空 |
| API契约缺失 | 审查范围受限 | 无法做接口级审查 |
| 业务规模未指定 | 默认中等规模 | 架构模式可能不匹配 |
上游变更响应
| 上游变更 | 影响范围 | 响应策略 |
|---|
| PRD业务领域变更 | 服务拆分 | 标注受影响的服务边界，评估是否需要重新划分 |
| 数据模型变更 | 服务数据归属 | 标注受影响的服务，评估数据迁移需求 |
| API契约变更 | 审查结果 | 重新评估受影响接口的安全和性能 |
