Backend Patterns

2. 架构设计（结论先行）

先输出架构分层总览表，再展开细节：

## 架构分层总览

| Layer        | 职责                          | 依赖             |
| ------------ | ----------------------------- | ---------------- |
| Controller   | 请求解析、响应构造、验证       | Service          |
| Service      | 业务逻辑、编排                 | Repository       |
| Repository   | 数据访问抽象                   | DB Client / ORM  |
| Middleware    | 横切关注点（认证、日志、限流） | 无状态           |
| Cache        | 缓存层装饰器                   | Repository       |

根据需求从以下 references 中选择适用的模式：

• 分层架构: references/architecture-patterns.md
• 数据库优化: references/database-optimization.md
• 缓存策略: references/caching-strategies.md
• 弹性模式: references/resilience-patterns.md

3. 代码生成

按以下顺序生成输出物：

A. Repository 层

• 文件: repositories/{resource}.repository.ts
• 接口定义 + 具体实现
• 数据库错误映射
• 遵循 references/architecture-patterns.md 中的 Repository 模式

B. Service 层

• 文件: services/{resource}.service.ts
• 业务逻辑与数据访问分离
• 依赖注入（构造函数注入）
• 遵循 references/architecture-patterns.md 中的 Service 模式

C. 缓存层（如需要）

• 文件: cache/{resource}.cache.ts
• 装饰器模式包装 Repository
• 遵循 references/caching-strategies.md

D. 中间件

• 文件: middleware/{concern}.ts
• 限流、日志、请求追踪
• 遵循 references/resilience-patterns.md

4. 设计审查

生成完成后，自动检查以下规则：

• Repository 接口与实现分离
• Service 层不直接访问数据库客户端
• Controller 不包含业务逻辑
• 遵循统一响应信封 → 参见 api-design 响应规范
• N+1 查询问题已通过批量查询解决（应用层 batching）
• SELECT 仅选取需要的列（非 SELECT *）
• 事务中包含正确的回滚处理
• 缓存设置了合理的 TTL
• 缓存在数据变更时主动失效
• 限流策略已在关键端点上生效（实现 owner）
• 日志规范 → 参见 observability 日志审查项
• 不可变模式（readonly 属性、新对象创建）
• 无硬编码配置值

Output Format

# Backend Architecture: {项目名称}

## 架构分层总览
{分层表格}

## Repository 层
{接口定义 + 实现代码}

## Service 层
{业务逻辑代码}

## 缓存层
{缓存装饰器代码（如适用）}

## 中间件
{限流 / 日志 / 追踪代码}

## 数据库优化
{查询优化建议 + 索引建议}

## 设计审查
{审查结果清单，标记通过/未通过}