Designing a new system or major feature from scratch
Evaluating trade-offs between architectural approaches
Creating Architecture Decision Records (ADRs)
Reviewing existing architecture for scalability, reliability, or maintainability concerns
Decomposing a monolith or planning a migration

从零开始设计新系统或主要功能
评估不同架构方案之间的权衡
创建架构决策记录（ADRs）
审查现有架构的可扩展性、可靠性或可维护性问题
拆分单体应用或规划迁移

Workflow

工作流程

Step 1: Clarify Requirements

步骤1：明确需求

Before designing, gather:

Functional requirements - What must the system do?
Non-functional requirements - Performance, availability, security, cost constraints
Scope boundaries - What is explicitly out of scope?
Existing constraints - Current tech stack, team skills, timeline

Ask the user to clarify any ambiguous requirements before proceeding.

设计前，需收集：

功能需求 - 系统必须实现哪些功能？
非功能需求 - 性能、可用性、安全性、成本约束
范围边界 - 明确哪些内容不在范围内？
现有约束 - 当前技术栈、团队技能、时间线

请用户在继续前澄清任何模糊的需求。

Step 2: Identify Components

步骤2：识别组件

Break the system into components:

Data stores - What data exists? How is it accessed?
Services / modules - What are the logical units of work?
Interfaces - How do components communicate? (API, events, shared DB, files)
External dependencies - Third-party services, APIs, infrastructure

将系统拆分为以下组件：

数据存储 - 存在哪些数据？如何访问？
服务/模块 - 逻辑工作单元有哪些？
接口 - 组件之间如何通信？（API、事件、共享数据库、文件）
外部依赖 - 第三方服务、API、基础设施

Step 3: Evaluate Alternatives

步骤3：评估备选方案

For each significant decision, document at least 2 options:

Criterion	Option A	Option B
Complexity	...	...
Scalability	...	...
Operational cost	...	...
Team familiarity	...	...

Recommend one option with clear reasoning.

对于每个重要决策，记录至少2个选项：

评估标准	选项A	选项B
复杂度	...	...
可扩展性	...	...
运营成本	...	...
团队熟悉度	...	...

推荐一个选项并给出清晰的理由。

Step 4: Produce Design Artifact

步骤4：生成设计产物

Output a structured design document:

markdown

undefined

输出结构化的设计文档：

markdown

undefined

Design: <Title>

设计：<标题>

[Problem statement and motivation]

[问题陈述与动机]

Functional: ...
Non-functional: ...

功能：...
非功能：...

[Component diagram or description]

[组件图或描述]

Key Decisions

关键决策

Decision	Choice	Rationale
...	...	...

决策内容	选择	理由
...	...	...

Data Model

数据模型

[Schema or entity relationships]

[Schema或实体关系]

API Surface

API 接口

[Key endpoints or interfaces]

[核心端点或接口]

Risks & Mitigations

风险与缓解措施

Risk	Impact	Mitigation
...	...	...

风险	影响	缓解方案
...	...	...

Open Questions

待解决问题

undefined

undefined

Step 5: Review Checklist

步骤5：审查清单

Before finalizing, verify:

Single responsibility per component
No circular dependencies between modules
Failure modes identified and handled
Data consistency model is explicit (strong vs eventual)
Security boundaries are defined
Observability points (logging, metrics, tracing) are planned

最终确定前，验证以下内容：

每个组件单一职责
模块之间无循环依赖
已识别并处理故障模式
数据一致性模型明确（强一致性 vs 最终一致性）
已定义安全边界
已规划可观测性点（日志、指标、追踪）

Principles

设计原则

Start simple - Add complexity only when requirements demand it
Make trade-offs explicit - Every choice has a cost; document it
Design for change - Interfaces should be stable; implementations should be replaceable
Separate concerns - Data, logic, and presentation should not be entangled
Fail gracefully - Design for partial failures, not just the happy path

从简开始 - 仅在需求要求时增加复杂度
明确权衡 - 每个选择都有成本，需记录下来
为变更设计 - 接口应保持稳定；实现应可替换
关注点分离 - 数据、逻辑和展示不应相互纠缠
优雅容错 - 针对部分故障设计，而非仅考虑理想路径

system-design

Original

Translation

System Design

系统设计

When to Use

适用场景