系統架構設計範本

Prompt 目標

指導 AI 進行完整的系統架構設計，產生技術架構文檔和設計決策說明。

角色設定

你是一位資深系統架構師，具備豐富的大型系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。

任務描述

請協助我完成 {專案名稱} 的系統架構設計工作。

專案技術背景

專案名稱: {填入專案名稱}
系統類型: {填入系統類型，如：Web應用、微服務、分散式系統}
預期使用者規模: {填入使用者數量級，如：1000、10萬、100萬}
效能要求: {填入關鍵效能指標}
技術棧偏好: {填入偏好的技術棧，如：Java/Spring、.NET、Python/Django}
部署環境: {填入部署方式，如：雲端、地端、混合雲}

架構設計要求

請按照以下結構進行系統架構設計：

1. 系統概覽

系統邊界定義
主要組件識別
系統上下文圖
利害關係人視圖

2. 架構風格選擇

架構風格評估
設計原則定義
品質屬性分析
技術決策記錄

3. 邏輯架構設計

分層架構設計
組件劃分
介面定義
資料流設計

4. 物理架構設計

部署拓撲
基礎設施規劃
網路設計
安全架構

5. 技術選型

框架和函式庫選擇
資料庫技術選型
中介軟體選擇
工具和平台決策

6. 品質屬性設計

可用性設計
效能最佳化
安全性設計
可維護性考量

輸出格式

# {專案名稱} 系統架構設計文檔

## 1. 系統概覽

### 1.1 系統目標
**主要目標:** [系統主要目標描述]
**次要目標:** [次要目標列表]
**成功標準:** [可測量的成功指標]

### 1.2 系統邊界
**包含範圍:**
- [功能模組1]
- [功能模組2]
- [功能模組3]

**排除範圍:**
- [不包含的功能1]
- [不包含的功能2]

### 1.3 系統上下文圖

[使用者] –> [系統] –> [外部系統A] | v [外部系統B]


### 1.4 利害關係人需求
| 利害關係人 | 關注點 | 品質屬性要求 |
|------------|--------|--------------|
| [使用者] | [關注點] | [效能、可用性等] |
| [開發者] | [關注點] | [可維護性、可測試性等] |
| [運維人員] | [關注點] | [可監控性、可部署性等] |

## 2. 架構風格與原則

### 2.1 架構風格選擇
**選擇的架構風格:** [分層架構/微服務/事件驅動/等]
**選擇理由:**
- [理由1: 符合系統規模需求]
- [理由2: 滿足團隊技術能力]
- [理由3: 支援未來擴展需求]

### 2.2 設計原則
1. **單一職責原則 (SRP)**: [應用說明]
2. **開放封閉原則 (OCP)**: [應用說明]
3. **依賴反轉原則 (DIP)**: [應用說明]
4. **關注點分離 (SoC)**: [應用說明]
5. **低耦合高內聚**: [應用說明]

### 2.3 品質屬性優先級
| 品質屬性 | 優先級 | 目標值 | 設計策略 |
|----------|--------|---------|----------|
| 效能 | 高 | [具體目標] | [設計策略] |
| 可用性 | 高 | [具體目標] | [設計策略] |
| 安全性 | 中 | [具體目標] | [設計策略] |
| 可維護性 | 中 | [具體目標] | [設計策略] |

## 3. 邏輯架構設計

### 3.1 分層架構

┌─────────────────────────────────────┐ │ 表現層 (Presentation) │ ├─────────────────────────────────────┤ │ 應用層 (Application) │ ├─────────────────────────────────────┤ │ 領域層 (Domain) │ ├─────────────────────────────────────┤ │ 基礎設施層 (Infrastructure) │ └─────────────────────────────────────┘


### 3.2 核心組件設計

#### 組件: [組件名稱]
**職責:** [組件主要職責]
**介面:**
```java
public interface ComponentInterface {
    ResultType method1(ParameterType param);
    void method2(ParameterType param);
}

依賴關係: [依賴的其他組件] 品質屬性: [相關的品質需求]

3.3 資料流設計

輸入資料 → 驗證層 → 業務邏輯層 → 資料存取層 → 資料庫
                                ↓
輸出資料 ← 格式化層 ← 處理結果層 ←─────────┘

4. 物理架構設計

4.1 部署架構圖

┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
│   負載平衡器     │──→│   Web伺服器群    │──→│   應用伺服器群   │
│   (Load Balancer)│   │   (Web Servers)  │   │  (App Servers)   │
└─────────────────┘   └─────────────────┘   └─────────────────┘
                                                      │
                                                      ↓
                      ┌─────────────────┐   ┌─────────────────┐
                      │     快取層      │   │     資料庫群     │
                      │    (Cache)      │   │   (Databases)    │
                      └─────────────────┘   └─────────────────┘

4.2 硬體需求規劃

組件類型	數量	CPU	記憶體	儲存空間	網路
Web伺服器	2台	4核心	8GB	100GB SSD	1Gbps
應用伺服器	3台	8核心	16GB	200GB SSD	1Gbps
資料庫伺服器	2台	8核心	32GB	1TB SSD	10Gbps

4.3 網路設計

網路分段:

DMZ區域: Web伺服器
應用區域: 應用伺服器
資料區域: 資料庫伺服器

安全控制:

防火牆規則配置
VPN存取控制
網路監控設置

5. 技術選型

5.1 開發框架

後端框架: [框架名稱] 選擇理由: [效能、社群支援、團隊熟悉度等] 版本: [具體版本] 替代方案: [備選框架及比較]

5.2 資料庫技術

主資料庫: [資料庫名稱] 選擇理由: [ACID特性、效能、擴展性等] 快取技術: [快取解決方案] 資料備份策略: [備份方案]

5.3 中介軟體

訊息佇列: [MQ技術選擇] API閘道: [閘道技術] 監控工具: [監控解決方案] CI/CD工具: [持續整合工具]

5.4 雲端服務 (如適用)

雲端供應商: [AWS/Azure/GCP等] 核心服務: [使用的雲端服務清單] 成本估算: [大概的成本預估]

6. 品質屬性實現

6.1 效能設計

效能目標:

響應時間: < 2秒 (95%的請求)
吞吐量: > 1000 TPS
並發使用者: > 10,000

效能策略:

快取機制設計
資料庫最佳化
負載平衡配置
CDN內容分發

6.2 可用性設計

可用性目標: 99.9% (每月停機時間 < 43分鐘)

高可用策略:

服務冗餘設計
自動故障切換
健康檢查機制
災難復原計畫

6.3 安全性設計

安全策略:

身份驗證機制
授權控制
資料加密
安全監控

6.4 可維護性設計

維護性策略:

模組化設計
程式碼規範
自動化測試
文檔標準化

7. 風險與限制

7.1 技術風險

風險項目	風險等級	影響範圍	緩解策略
[風險1]	[高/中/低]	[影響描述]	[緩解措施]

7.2 架構限制

技術限制: [技術約束條件]
資源限制: [人力、時間、預算限制]
業務限制: [業務規則或政策限制]

8. 實施計畫

8.1 開發階段規劃

階段1: 基礎架構建置

核心框架設置
基礎組件開發
資料庫設計實作

階段2: 核心功能開發

主要業務邏輯實作
API介面開發
單元測試撰寫

階段3: 整合與最佳化

系統整合測試
效能調校
安全加固

8.2 遷移策略 (如適用)

遷移方式: [大爆炸式/分階段/並行運行] 資料遷移計畫: [資料遷移步驟] 回退計畫: [失敗時的回退策略]


## 架構設計最佳實務

### 架構決策記錄 (ADR)
每個重要的架構決策都應該記錄：
- **決策內容**: 做出了什麼決策
- **決策背景**: 為什麼需要這個決策
- **考慮選項**: 評估了哪些替代方案
- **決策結果**: 選擇的理由和影響
- **後果**: 決策的正面和負面影響

### C4 模型應用
1. **Context 圖**: 系統與外部環境的關係
2. **Container 圖**: 系統內部的高層級組件
3. **Component 圖**: 容器內部的組件結構
4. **Code 圖**: 組件內部的類別關係

## 品質檢查清單

- [ ] 系統邊界清楚定義
- [ ] 架構風格選擇有理由支撐
- [ ] 組件職責劃分清楚
- [ ] 介面設計完整
- [ ] 品質屬性需求可實現
- [ ] 技術選型有評估比較
- [ ] 部署架構可行
- [ ] 風險識別完整
- [ ] 實施計畫具體
- [ ] 架構決策有記錄

## 使用範例

### 範例專案：電子商務平台

#### 系統上下文

[顧客] ──→ [電商平台] ──→ [支付系統] │ ├──→ [庫存系統] ├──→ [物流系統] └──→ [通知服務]


#### 技術選型範例
- **後端**: Spring Boot + Java 17
- **資料庫**: PostgreSQL (主) + Redis (快取)
- **前端**: React + TypeScript
- **部署**: Docker + Kubernetes
- **監控**: Prometheus + Grafana

## 注意事項

1. 確保架構設計與業務需求對齊
2. 考慮系統的演進和擴展性
3. 平衡複雜度與實用性
4. 重視非功能性需求
5. 建立明確的架構治理機制
6. 定期檢視和更新架構設計

系統架構設計範本#

Prompt 目標#

角色設定#

任務描述#

專案技術背景#

架構設計要求#

1. 系統概覽#

2. 架構風格選擇#

3. 邏輯架構設計#

4. 物理架構設計#

5. 技術選型#

6. 品質屬性設計#

輸出格式#

3.3 資料流設計#

4. 物理架構設計#

4.1 部署架構圖#

4.2 硬體需求規劃#

4.3 網路設計#

5. 技術選型#

5.1 開發框架#

5.2 資料庫技術#

5.3 中介軟體#

5.4 雲端服務 (如適用)#

6. 品質屬性實現#

6.1 效能設計#

6.2 可用性設計#

6.3 安全性設計#

6.4 可維護性設計#

7. 風險與限制#

7.1 技術風險#

7.2 架構限制#

8. 實施計畫#

8.1 開發階段規劃#

8.2 遷移策略 (如適用)#

系統架構設計範本

Prompt 目標

角色設定

任務描述

專案技術背景

架構設計要求

1. 系統概覽

2. 架構風格選擇

3. 邏輯架構設計

4. 物理架構設計

5. 技術選型

6. 品質屬性設計

輸出格式

3.3 資料流設計

4. 物理架構設計

4.1 部署架構圖

4.2 硬體需求規劃

4.3 網路設計

5. 技術選型

5.1 開發框架

5.2 資料庫技術

5.3 中介軟體

5.4 雲端服務 (如適用)

6. 品質屬性實現

6.1 效能設計

6.2 可用性設計

6.3 安全性設計

6.4 可維護性設計

7. 風險與限制

7.1 技術風險

7.2 架構限制

8. 實施計畫

8.1 開發階段規劃

8.2 遷移策略 (如適用)