designing-architecture by cloudai-x/claude-workflow-v2
npx skills add https://github.com/cloudai-x/claude-workflow-v2 --skill designing-architecture复制此清单并跟踪进度:
架构设计进度:
- [ ] 步骤 1:理解需求和约束条件
- [ ] 步骤 2:评估项目规模和团队能力
- [ ] 步骤 3:选择架构模式
- [ ] 步骤 4:定义目录结构
- [ ] 步骤 5:记录权衡与决策
- [ ] 步骤 6:根据决策框架进行验证
| 规模 | 推荐模式 |
|---|---|
| 小型 (<10K LOC) | 简单 MVC/分层架构 |
| 中型 (10K-100K) | 整洁架构 |
| 大型 (>100K) | 模块化单体或微服务 |
| 团队 | 推荐 |
|---|---|
| 1-3 名开发者 | 具有清晰模块的单体架构 |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 4-10 名开发者 | 模块化单体架构 |
| 10+ 名开发者 | 微服务(如果合理) |
┌─────────────────────────────┐
│ 表示层 │ ← UI, API 控制器
├─────────────────────────────┤
│ 应用层 │ ← 用例、服务
├─────────────────────────────┤
│ 领域层 │ ← 业务逻辑、实体
├─────────────────────────────┤
│ 基础设施层 │ ← 数据库、外部 API
└─────────────────────────────┘
适用场景 : 简单的 CRUD 应用、小型团队、快速原型
┌─────────────────────────────────────┐
│ 框架与驱动层 │
│ ┌─────────────────────────────┐ │
│ │ 接口适配器层 │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ 应用层 │ │ │
│ │ │ ┌─────────────┐ │ │ │
│ │ │ │ 领域层 │ │ │ │
│ │ │ └─────────────┘ │ │ │
│ │ └─────────────────────┘ │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
适用场景 : 复杂的业务逻辑、长期项目、可测试性至关重要
┌──────────┐
│ HTTP API │
└────┬─────┘
│ 端口
┌────────▼────────┐
│ │
│ 应用核心 │
│ │
└────────┬────────┘
│ 端口
┌────▼─────┐
│ 数据库 │
└──────────┘
适用场景 : 需要替换外部依赖、具有多个入口点
生产者 → 事件总线 → 消费者
│
├─→ 消费者
│
└─→ 消费者
适用场景 : 需要松耦合、异步处理、可扩展性
┌─────────────┐ ┌─────────────┐
│ 命令 │ │ 查询 │
│ (写操作) │ │ (读操作) │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
写模型 读模型
│ │
└────────┬───────────┘
▼
事件存储
适用场景 : 读写操作扩展需求不同、复杂领域、事件溯源
src/
├── features/
│ ├── users/
│ │ ├── api/
│ │ ├── components/
│ │ ├── hooks/
│ │ ├── services/
│ │ └── types/
│ └── orders/
│ ├── api/
│ ├── components/
│ └── ...
├── shared/
│ ├── components/
│ ├── hooks/
│ └── utils/
└── app/
└── ...
src/
├── controllers/
├── services/
├── models/
├── repositories/
└── utils/
进行架构决策时,请根据以下标准进行评估:
使用此模板记录架构决策:
## 决策:[我们正在决定什么]
### 背景
[为什么现在需要做这个决策]
### 考虑的选项
1. 选项 A:[描述]
2. 选项 B:[描述]
### 权衡
| 标准 | 选项 A | 选项 B |
| ---------------- | -------- | -------- |
| 复杂度 | 低 | 高 |
| 可扩展性 | 中 | 高 |
| 团队熟悉度 | 高 | 低 |
### 决策
我们选择[选项],因为[理由]。
### 后果
- [这能实现什么]
- [这会限制什么]
选择架构后,请根据以下内容进行验证:
架构验证:
- [ ] 匹配项目规模和复杂度
- [ ] 与团队技能和经验相符
- [ ] 支持当前需求
- [ ] 允许预期的增长
- [ ] 依赖关系向内流动(核心没有外部依赖)
- [ ] 模块/层之间有清晰的边界
- [ ] 测试策略可行
- [ ] 权衡已记录
如果验证失败,请重新考虑模式选择或调整实现方法。
每周安装量
63
代码仓库
GitHub 星标数
1.3K
首次出现
Jan 22, 2026
安全审计
安装于
codex48
opencode48
gemini-cli47
claude-code47
github-copilot43
cursor39
Copy this checklist and track progress:
Architecture Design Progress:
- [ ] Step 1: Understand requirements and constraints
- [ ] Step 2: Assess project size and team capabilities
- [ ] Step 3: Select architecture pattern
- [ ] Step 4: Define directory structure
- [ ] Step 5: Document trade-offs and decision
- [ ] Step 6: Validate against decision framework
| Size | Recommended Pattern |
|---|---|
| Small (<10K LOC) | Simple MVC/Layered |
| Medium (10K-100K) | Clean Architecture |
| Large (>100K) | Modular Monolith or Microservices |
| Team | Recommended |
|---|---|
| 1-3 devs | Monolith with clear modules |
| 4-10 devs | Modular Monolith |
| 10+ devs | Microservices (if justified) |
┌─────────────────────────────┐
│ Presentation │ ← UI, API Controllers
├─────────────────────────────┤
│ Application │ ← Use Cases, Services
├─────────────────────────────┤
│ Domain │ ← Business Logic, Entities
├─────────────────────────────┤
│ Infrastructure │ ← Database, External APIs
└─────────────────────────────┘
Use when : Simple CRUD apps, small teams, quick prototypes
┌─────────────────────────────────────┐
│ Frameworks & Drivers │
│ ┌─────────────────────────────┐ │
│ │ Interface Adapters │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ Application │ │ │
│ │ │ ┌─────────────┐ │ │ │
│ │ │ │ Domain │ │ │ │
│ │ │ └─────────────┘ │ │ │
│ │ └─────────────────────┘ │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
Use when : Complex business logic, long-lived projects, testability is key
┌──────────┐
│ HTTP API │
└────┬─────┘
│ Port
┌────────▼────────┐
│ │
│ Application │
│ Core │
│ │
└────────┬────────┘
│ Port
┌────▼─────┐
│ Database │
└──────────┘
Use when : Need to swap external dependencies, multiple entry points
Producer → Event Bus → Consumer
│
├─→ Consumer
│
└─→ Consumer
Use when : Loose coupling needed, async processing, scalability
┌─────────────┐ ┌─────────────┐
│ Commands │ │ Queries │
│ (Write) │ │ (Read) │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
Write Model Read Model
│ │
└────────┬───────────┘
▼
Event Store
Use when : Different read/write scaling, complex domains, event sourcing
src/
├── features/
│ ├── users/
│ │ ├── api/
│ │ ├── components/
│ │ ├── hooks/
│ │ ├── services/
│ │ └── types/
│ └── orders/
│ ├── api/
│ ├── components/
│ └── ...
├── shared/
│ ├── components/
│ ├── hooks/
│ └── utils/
└── app/
└── ...
src/
├── controllers/
├── services/
├── models/
├── repositories/
└── utils/
When making architectural decisions, evaluate against these criteria:
Use this template to document architectural decisions:
## Decision: [What we're deciding]
### Context
[Why this decision is needed now]
### Options Considered
1. Option A: [Description]
2. Option B: [Description]
### Trade-offs
| Criteria | Option A | Option B |
| ---------------- | -------- | -------- |
| Complexity | Low | High |
| Scalability | Medium | High |
| Team familiarity | High | Low |
### Decision
We chose [Option] because [reasoning].
### Consequences
- [What this enables]
- [What this constrains]
After selecting an architecture, validate against:
Architecture Validation:
- [ ] Matches project size and complexity
- [ ] Aligns with team skills and experience
- [ ] Supports current requirements
- [ ] Allows for anticipated growth
- [ ] Dependencies flow inward (core has no external deps)
- [ ] Clear boundaries between modules/layers
- [ ] Testing strategy is feasible
- [ ] Trade-offs are documented
If validation fails, reconsider the pattern selection or adjust the implementation approach.
Weekly Installs
63
Repository
GitHub Stars
1.3K
First Seen
Jan 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex48
opencode48
gemini-cli47
claude-code47
github-copilot43
cursor39
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
122,000 周安装