viccom/software-architecture-design

軟體架構設計 — 快速參考

使用此技能進行系統層級的設計決策，而非單一服務或元件的實作細節。

快速參考

任務	模式/工具	主要資源	使用時機
選擇架構風格	分層、微服務、事件驅動、無伺服器	modern-patterns.md	綠地專案、重大重構
設計可擴展性	負載平衡、快取、分片、讀取複本	scalability-reliability-guide.md	高流量系統、效能目標
確保韌性	斷路器、重試、隔艙壁、優雅降級	scalability-reliability-guide.md	分散式系統、外部依賴
記錄決策	架構決策記錄 (ADR)	adr-template.md	重大技術決策、權衡分析
定義服務邊界	領域驅動設計 (DDD)、限定上下文	microservices-template.md	微服務拆分
建模資料一致性	ACID vs BASE、事件溯源、CQRS、Saga 模式	data-architecture-patterns.md	跨服務交易
規劃可觀測性	SLI/SLO/SLA、分散式追蹤、指標、日誌	architecture-blueprint.md	生產就緒
從單體式遷移	絞殺者模式、資料庫拆分、影子流量	migration-modernization-guide.md	舊系統現代化
設計服務間通訊	API 閘道器、服務網格、BFF 模式	api-gateway-service-mesh.md	微服務網路

何時使用此技能

在處理以下工作時調用：

• 系統拆分：在單體式、模組化單體式、微服務之間做決定
• 架構模式：事件驅動、CQRS、分層、六邊形、無伺服器
• 資料架構：一致性模型、分片、複寫、CQRS 模式
• 可擴展性設計：負載平衡、快取策略、資料庫擴展
• 韌性模式：斷路器、重試、隔艙壁、優雅降級
• API 合約：服務邊界、版本控制、整合模式
• 架構決策：ADR、權衡分析、技術選擇
• 遷移規劃：單體拆分、絞殺者模式、資料庫分離

何時不應使用此技能

請改用其他技能來處理：

• 單一服務實作（路由、控制器、業務邏輯）→ software-backend
• API 端點設計（REST 慣例、GraphQL schema）→ dev-api-design
• 安全性實作（認證、加密、OWASP）→ software-security-appsec
• 前端元件架構 → software-frontend
• 資料庫查詢最佳化 → data-sql-optimization

決策樹：選擇架構模式

專案需求：[新建系統或重大重構]
    ├─ 單一團隊，領域不斷演化？
    │   ├─ 從簡單開始 → 模組化單體式（清晰的模組邊界）
    │   └─ 需要快速迭代 → 分層架構
    │
    ├─ 多個團隊，有清晰的限定上下文？
    │   ├─ 獨立部署至關重要 → 微服務
    │   └─ 共享資料模型 → 結合服務模組的模組化單體式
    │
    ├─ 事件驅動工作流程？
    │   ├─ 非同步處理 → 事件驅動架構 (Kafka, 佇列)
    │   └─ 複雜狀態機 → Saga 模式 + 事件溯源
    │
    ├─ 可變/不可預測的負載？
    │   ├─ 按用量付費模式 → 無伺服器 (AWS Lambda, Cloudflare Workers)
    │   └─ 批次處理 → 無伺服器 + 佇列
    │
    └─ 高一致性需求？
        ├─ 強 ACID 保證 → 單體式或模組化單體式
        └─ 分散式資料 → CQRS + 事件溯源

決策因素：

• 團隊規模門檻：<10 位開發人員 → 模組化單體式通常優於微服務（營運開銷）
• 團隊結構（康威定律）— 架構反映組織結構
• 獨立部署的需求
• 一致性 vs 可用性的權衡（CAP 定理）
• 營運成熟度（監控、編排）

詳見 references/modern-patterns.md 以取得詳細的模式說明。

輸出指南

此技能中的參考資料是供您吸收的背景知識 — 將這些模式視為您的專業知識來呈現。請勿在使用者可見的輸出中引用內部參考檔案名稱（例如「來自 data-architecture-patterns.md」）。使用者不知道這些檔案的存在。

每個架構建議都應包含：

• 具體的技術選擇：指定具體技術（例如「使用 Temporal.io 進行工作流程編排」、「使用 Socket.io 搭配 Redis 適配器」），而不是停留在抽象層面。使用者需要做出建置決策，而不僅僅是理解模式。
• 不該建構的內容：明確指出哪些事項應延後或避免。過早擴大範圍是架構的第一大錯誤 — 幫助使用者避免它。
• 團隊與流程對齊：此架構如何對應到團隊結構？它隱含了什麼樣的擁有權模型？在相關處納入 CODEOWNERS、部署擁有權和待命界線。
• 成功指標：團隊如何知道架構正在運作？包含可衡量的指標（部署頻率、交付時間、錯誤率、MTTR）。
• 重點式的篇幅：專注於 3–5 個最重要的決策，而非詳盡涵蓋所有考量。過長的建議將不會被遵循。

工作流程（系統層級）

在使用者尋求架構建議、拆分或重大平台決策時，使用此工作流程。

1. 釐清：問題陳述、非目標、限制條件和成功指標
2. 擷取品質屬性：可用性、延遲、吞吐量、持久性、一致性、安全性、合規性、成本
3. 提出 2–3 個候選架構並比較權衡取捨
4. 定義邊界：限定上下文、擁有權、API/事件、整合合約
5. 決定資料策略：儲存方式、一致性模型、schema 演進、遷移
6. 設計營運面：SLO、故障模式、可觀測性、部署、災難復原、事故應變手冊
7. 指出範圍限制：尚不該建構的內容、應延後的事項、應購買 vs 自行建置的項目
8. 記錄決策：為關鍵權衡和不可逆轉的選擇撰寫 ADR

偏好的交付產物（根據需求選擇）：

• 架構藍圖：assets/planning/architecture-blueprint.md
• 決策記錄：assets/planning/adr-template.md
• 模式深入探討：references/modern-patterns.md、references/scalability-reliability-guide.md

2026 年考量事項

僅在問題明確涉及當前趨勢、供應商特定限制或「關於 X 的最新想法是什麼？」時才載入。

• references/architecture-trends-2026.md — 平台工程、資料網格、可組合架構、AI 原生系統
• data/sources.json — 60 個精選資源，依類別組織：
  • platform_engineering_2026 — IDP 趨勢、AI-平台匯流、Backstage
  • optional_ai_architecture — RAG 模式、多代理設計、MCP/A2A 協定
  • modern_architecture_2025 — 資料網格、可組合架構、持續架構

如果可存取即時網路，請查閱 data/sources.json 中的 2–3 個權威來源，並將發現結果納入建議中。如果無法存取，則以經得起考驗的模式回答，並明確陳述可能改變的假設（供應商限制、定價、受管服務能力）。

導航

核心參考資料

每個問題最多閱讀 2–3 份參考資料 — 選擇與特定問題最相關的資料。請勿全部閱讀。

參考資料	內容	閱讀時機
modern-patterns.md	10 種架構模式及決策樹	選擇或比較模式時
scalability-reliability-guide.md	CAP 定理、資料庫擴展、快取、斷路器、SRE	處理擴展或可靠性問題時
data-architecture-patterns.md	CQRS 變體、事件溯源、資料網格、Saga、一致性	處理跨服務資料流時
migration-modernization-guide.md	絞殺者模式、資料庫拆分、功能開關、風險評估	重構單體式應用時
api-gateway-service-mesh.md	閘道器模式、服務網格、mTLS、可觀測性	處理服務間通訊時
architecture-trends-2026.md	平台工程、資料網格、AI 原生系統	僅在處理當前趨勢時
operational-playbook.md	架構問題框架、拆分啟發式方法	進行設計討論框架時

範本

規劃與文件（assets/planning/）：

• architecture-blueprint.md — 服務藍圖（依賴、SLA、資料流、韌性、安全性、可觀測性）
• adr-template.md — 用於權衡分析的架構決策記錄

架構模式（assets/patterns/）：

• microservices-template.md — 微服務設計（API 合約、韌性、部署、測試）
• event-driven-template.md — 事件驅動架構（事件 schema、Saga 模式、事件溯源）

營運（assets/operations/）：

• scalability-checklist.md — 可擴展性檢查清單（資料庫擴展、快取、負載測試、自動擴展、災難復原）

相關技能

• software-backend — 後端工程、API 實作、資料層
• software-frontend — 前端架構、微前端、狀態管理
• dev-api-design — REST、GraphQL、gRPC 設計模式
• ops-devops-platform — CI/CD、部署策略、基礎架構即程式碼
• qa-observability — 監控、追蹤、告警、SLO
• software-security-appsec — 威脅建模、認證、安全設計
• data-sql-optimization — 資料庫設計、最佳化、索引
• docs-codebase — 架構文件、C4 圖表、ADR