Loading...
Loading...
Compare original and translation side by side
NO ARCHITECTURE DESIGN BEFORE FUNCTIONALITY FLOWS ARE MAPPEDNO ARCHITECTURE DESIGN BEFORE FUNCTIONALITY FLOWS ARE MAPPED| Request Type | Route To |
|---|---|
| "Design API endpoints" | API Design section |
| "Plan system architecture" | Full Architecture Design |
| "Design data models" | Data Model section |
| "Plan integrations" | Integration Patterns section |
| "Make decisions" | Decision Framework section |
| 请求类型 | 路由至 |
|---|---|
| "设计API端点" | API设计板块 |
| "规划系统架构" | 完整架构设计 |
| "设计数据模型" | 数据模型板块 |
| "规划集成方案" | 集成模式板块 |
| "制定决策" | 决策框架板块 |
User Flow (example):
1. User opens upload page
2. User selects file
3. System validates file type/size
4. System uploads to storage
5. System shows success message
Admin Flow (example):
1. Admin opens dashboard
2. Admin views all uploads
3. Admin can delete uploads
4. System logs admin action
System Flow (example):
1. Request received at API
2. Auth middleware validates token
3. Service processes request
4. Database stores data
5. Response returned用户流程（示例）：
1. 用户打开上传页面
2. 用户选择文件
3. 系统验证文件类型/大小
4. 系统将文件上传至存储服务
5. 系统显示成功提示
管理员流程（示例）：
1. 管理员打开控制台
2. 管理员查看所有上传记录
3. 管理员可删除上传记录
4. 系统记录管理员操作
系统流程（示例）：
1. API接收到请求
2. 认证中间件验证令牌
3. 服务处理请求
4. 数据库存储数据
5. 返回响应| Flow Step | Architecture Component |
|---|---|
| User opens page | Frontend route + component |
| User submits data | API endpoint |
| System validates | Validation service |
| System processes | Business logic service |
| System stores | Database + repository |
| System integrates | External client/adapter |
| 流程步骤 | 架构组件 |
|---|---|
| 用户打开页面 | 前端路由 + 组件 |
| 用户提交数据 | API端点 |
| 系统验证 | 验证服务 |
| 系统处理 | 业务逻辑服务 |
| 系统存储 | 数据库 + 数据访问层 |
| 系统集成 | 外部客户端/适配器 |
┌─────────────────────────────────────────────┐
│ SYSTEM │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Web │ │ API │ │Database │ │
│ │ App │──│ Service │──│ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────┘
│ │ │
┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│User │ │Admin│ │ Ext │
└─────┘ └─────┘ └─────┘┌─────────────────────────────────────────────┐
│ SYSTEM │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Web │ │ API │ │Database │ │
│ │ App │──│ Service │──│ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────┘
│ │ │
┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│User │ │Admin│ │ Ext │
└─────┘ └─────┘ └─────┘| Architecture Task | LSP Tool | Output |
|---|---|---|
| Map component dependencies | | What each component uses |
| Find all consumers of a service | | Impact analysis |
| Verify interface implementations | | All implementers |
| Trace data flow | Chain | Full flow map |
1. localSearchCode("ServiceName") → find entry points
2. lspCallHierarchy(outgoing) → map dependencies
3. For each dependency: repeat step 2
4. Build dependency graph from results| 架构任务 | LSP工具 | 输出结果 |
|---|---|---|
| 映射组件依赖 | | 每个组件的依赖项 |
| 查找服务的所有调用方 | | 影响范围分析 |
| 验证接口实现 | | 所有实现类 |
| 追踪数据流 | 链式调用 | 完整数据流映射 |
1. localSearchCode("ServiceName") → 找到入口点
2. lspCallHierarchy(outgoing) → 映射依赖关系
3. 对每个依赖项：重复步骤2
4. 根据结果构建依赖关系图User Flow: Upload file
→ POST /api/files
Request: { file: binary, metadata: {...} }
Response: { id: string, url: string }
Errors: 400 (invalid), 413 (too large), 500 (storage failed)
User Flow: View file
→ GET /api/files/:id
Response: { id, url, metadata, createdAt }
Errors: 404 (not found), 403 (not authorized)
Admin Flow: Delete file
→ DELETE /api/files/:id
Response: { success: true }
Errors: 404, 403用户流程：上传文件
→ POST /api/files
请求：{ file: binary, metadata: {...} }
响应：{ id: string, url: string }
错误：400（无效请求）, 413（文件过大）, 500（存储失败）
用户流程：查看文件
→ GET /api/files/:id
响应：{ id, url, metadata, createdAt }
错误：404（未找到）, 403（无权限）
管理员流程：删除文件
→ DELETE /api/files/:id
响应：{ success: true }
错误：404, 403| Requirement | Pattern |
|---|---|
| Flaky external service | Retry with exponential backoff |
| Slow external service | Circuit breaker + timeout |
| Async processing needed | Message queue |
| Real-time updates needed | WebSocket/SSE |
| Data sync needed | Event sourcing |
undefined| 需求 | 模式 |
|---|---|
| 不稳定的外部服务 | 指数退避重试 |
| 响应缓慢的外部服务 | 断路器 + 超时 |
| 需要异步处理 | 消息队列 |
| 需要实时更新 | WebSocket/SSE |
| 需要数据同步 | 事件溯源 |
undefinedundefinedundefined| Aspect | Questions |
|---|---|
| Logging | What events? What level? Structured format? |
| Metrics | What to measure? Counters, gauges, histograms? |
| Alerts | What thresholds? Who gets notified? |
| Tracing | Span boundaries? Correlation IDs? |
| 维度 | 需明确的问题 |
|---|---|
| 日志 | 需要记录哪些事件？日志级别？是否采用结构化格式？ |
| 指标 | 需要衡量哪些指标？计数器、仪表盘、直方图？ |
| 告警 | 阈值是多少？通知对象是谁？ |
| 链路追踪 | 跨度边界？关联ID？ |
undefinedundefined| Criterion | Option A | Option B | Option C |
|---|---|---|---|
| Performance | Good | Better | Best |
| Complexity | Low | Medium | High |
| Cost | Low | Medium | High |
undefined| 评估标准 | 选项A | 选项B | 选项C |
|---|---|---|---|
| 性能 | 良好 | 较好 | 最佳 |
| 复杂度 | 低 | 中 | 高 |
| 成本 | 低 | 中 | 高 |
undefined| Excuse | Reality |
|---|---|
| "This pattern is industry standard" | Does it support THIS functionality? |
| "We might need it later" | YAGNI. Design for now. |
| "Microservices are better" | For this functionality? Justify it. |
| "Everyone uses this" | That's not a trade-off analysis. |
| "It's more flexible" | Flexibility without need = complexity. |
| 借口 | 实际情况 |
|---|---|
| “这个模式是行业标准” | 它是否支持当前的功能需求？ |
| “我们以后可能需要” | YAGNI（你不会需要它）。为当下设计即可。 |
| “微服务更好” | 对当前功能而言是否必要？请给出理由。 |
| “大家都在用这个” | 这不是权衡分析。 |
| “它更灵活” | 无需求的灵活性等于复杂度。 |
undefinedundefined| Component | Purpose (Functionality) | Dependencies |
|---|---|---|
| [Name] | [What flow it supports] | [What it needs] |
| 组件 | 用途（功能） | 依赖项 |
|---|---|---|
| [名称] | [支持哪些流程] | [所需依赖] |
| Endpoint | Flow | Request | Response |
|---|---|---|---|
| POST /api/x | User uploads | {...} | {...} |
| 端点 | 对应流程 | 请求 | 响应 |
|---|---|---|---|
| POST /api/x | 用户上传 | {...} | {...} |
undefinedundefined