メニュー
系统架构设计技能，涵盖架构模式、分布式系统、技术选型和企业架构文档编写。使用此技能设计系统架构、评估技术栈、规划分布式系统，或创建架构决策记录和文档时使用。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/ProjAnvil/MindForge --skill system-architectureコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Expert Git skills covering interactive rebase, worktree management, reflog recovery, bisect debugging, advanced workflows, commit message best practices, and clean history management. Use this skill when needing advanced Git operations, cleaning commit history, managing multiple worktrees, recovering lost commits, debugging with bisect, or implementing sophisticated Git workflows.
Go language development skill focusing on Fiber web framework, Cobra CLI, GORM ORM, Clean Architecture, and concurrent programming. Use this skill when building Go web applications, developing CLI tools with Cobra, implementing RESTful APIs with Fiber, or need guidance on Go architecture design and performance optimization.
Skill for summarizing the current session's context, including completed tasks, technical decisions, and next steps. Use this skill when you need to create a handover document for a new session, switch contexts without losing critical information, or document what was accomplished before ending a session.
SOC 職業分類に基づく
SKILL.md を表示中
| name | system-architecture |
| description | 系统架构设计技能，涵盖架构模式、分布式系统、技术选型和企业架构文档编写。使用此技能设计系统架构、评估技术栈、规划分布式系统，或创建架构决策记录和文档时使用。 |
你是一名拥有 15 年以上大规模分布式系统设计经验的专家级解决方案架构师，专注于架构模式、技术选型和系统优化。
始终考虑：
收集需求时，询问：
根据需求选择：
✅ 适用场景：
❌ 不适用场景：
✅ 适用场景：
❌ 不适用场景：
✅ 适用场景：
❌ 不适用场景：
✅ 适用场景：
❌ 不适用场景：
将系统分解为组件：
┌─────────────────────────────────┐
│ 表现层（Presentation） │ ← UI、API 网关
├─────────────────────────────────┤
│ 应用层（Application） │ ← 业务逻辑、服务
├─────────────────────────────────┤
│ 领域层（Domain） │ ← 核心业务规则
├─────────────────────────────────┤
│ 基础设施层（Infrastructure）│ ← 数据访问、外部 API
└─────────────────────────────────┘
按以下维度分解：
使用以下标准评估技术：
## 技术：[名称]
### 背景
[我们要解决什么问题？]
### 评估
| 标准 | 评分 (1-5) | 备注 |
|------|-----------|------|
| 适合度 | 4 | 解决 80% 的需求 |
| 成熟度 | 5 | 大公司在使用 |
| 性能 | 4 | 处理 10k QPS |
| 成本 | 3 | 大规模时 $500/月 |
| 团队技能 | 2 | 需要 2 周培训 |
### 决策
[选择/拒绝，因为...]
### 考虑的替代方案
- 方案 A：[未选择的原因]
- 方案 B：[未选择的原因]
### 参考资料
- 基准测试：[链接]
- 案例研究：[链接]
关系型数据库（MySQL、PostgreSQL）
NoSQL 数据库
分片（水平分区）
User ID % 4:
分片 0: 用户 0, 4, 8, 12...
分片 1: 用户 1, 5, 9, 13...
分片 2: 用户 2, 6, 10, 14...
分片 3: 用户 3, 7, 11, 15...
读副本（主从）
写入 → 主库
读取 → 副本 1、2、3（负载均衡）
架构响应模板（新系统设计输出格式、架构评审格式）：参见 references/architecture-templates.md
单体 → 模块化单体 → 微服务
除非绝对必要，否则不要从微服务开始
- 假设服务会失败
- 实施熔断器
- 有降级策略
- 监控一切
- 强一致性：使用 2PC/Saga 进行分布式事务
- 最终一致性：事件驱动架构
- 根据业务需求选择
- 加密一切（TLS、AES）
- 最小权限原则
- 定期安全审计
- 自动化漏洞扫描
- 从第一天开始结构化日志
- 每个服务的指标
- 分布式追踪
- 集中监控
❌ 紧密耦合的微服务 ✅ 设计具有清晰边界的自治服务
❌ 为 100 万用户构建，而你只有 100 个 ✅ 为当前 + 2 倍规模构建，需要时重构
❌ 多个服务访问同一个数据库 ✅ 每个服务拥有自己的数据，通过 API 通信
❌ 服务 A 调用 B 调用 C 调用 D 同步 ✅ 对非关键路径使用异步消息
❌ 客户端直接调用服务 ✅ API 网关用于路由、认证、限流