SAD 系統架構文件範本（System Architecture Document）#
參照標準：ISO/IEC/IEEE 42010:2022（取代 IEEE 1471-2000）
文件用途：描述系統架構決策、觀點、視圖與品質屬性，作為開發團隊的設計藍圖
適用階段：系統設計階段（System Design Phase）
📋 章節目錄#
- 文件資訊
- 架構概述
- 架構利害關係人與關注點
- 架構觀點定義
- 邏輯視圖
- 開發視圖
- 部署視圖
- 流程視圖
- 資料架構視圖
- 架構決策記錄
- 品質屬性與戰術
- 安全架構
- 附錄
1. 文件資訊#
📝 範本#
| 項目 | 內容 |
|---|
| 文件編號 | SAD-{專案代碼}-{序號} |
| 文件名稱 | {系統名稱} 系統架構文件 |
| 版本 | v{主版本}.{次版本} |
| 狀態 | 草稿 / 審核中 / 核定 |
| 建立日期 | {YYYY-MM-DD} |
| 最後更新 | {YYYY-MM-DD} |
| 架構師 | {姓名} |
| 審核者 | {姓名/角色} |
| 對應 FRD | {FRD 文件編號} |
版本歷程
| 版本 | 日期 | 修改人 | 修改內容摘要 |
|---|
| v0.1 | {YYYY-MM-DD} | {姓名} | 初版架構設計 |
📖 使用說明#
- 依據 ISO/IEC/IEEE 42010:2022 第 5.1 節，架構描述應包含識別資訊
- SAD 承接 FRD，將功能需求與非功能需求轉化為架構設計方案
- 架構文件是「活文件」（Living Document），隨設計演進持續更新
💡 範例#
| 項目 | 內容 |
|---|
| 文件編號 | SAD-HRM-001 |
| 文件名稱 | 人力資源管理系統 系統架構文件 |
| 版本 | v1.3 |
| 架構師 | 陳建築 |
| 對應 FRD | FRD-HRM-001 v2.1 |
2. 架構概述#
📝 範本#
2.1 系統背景（System Context）#
{描述系統在組織 IT 環境中的定位}
┌─────────────────────────────────────────────────────┐
│ 系統脈絡圖 │
│ │
│ [使用者] → [本系統] ←→ [外部系統 A] │
│ ↕ │
│ [外部系統 B] │
└─────────────────────────────────────────────────────┘
2.2 架構目標與原則#
架構目標：
架構原則（Architecture Principles）：
| 編號 | 原則 | 說明 | 影響 |
|---|
| AP-01 | {原則名稱} | {原則描述} | {對設計的影響} |
| AP-02 | {原則名稱} | {原則描述} | {對設計的影響} |
2.3 架構風格選擇#
| 項目 | 選擇 | 理由 |
|---|
| 整體架構風格 | {Monolithic / Microservices / SOA / Event-Driven} | {選擇理由} |
| 通訊模式 | {Sync / Async / Hybrid} | {選擇理由} |
| 資料管理 | {Shared DB / Database per Service} | {選擇理由} |
📖 使用說明#
- 系統脈絡圖：依 ISO/IEC/IEEE 42010 展示系統邊界與外部互動
- 架構原則：明確聲明指導設計的高層原則（如 Separation of Concerns、DRY）
- 架構風格：選擇需與非功能性需求（效能、可擴展性、維護性）對齊
- 此章節為整份 SAD 的摘要，讓讀者快速了解整體架構方向
💡 範例#
2.2 架構目標與原則#
架構目標：
- 支撐 500 並行使用者，P95 回應時間 ≤ 2 秒
- 系統可用性 99.5%，RTO ≤ 4 小時
- 支援水平擴展（Horizontal Scaling）
架構原則：
| 編號 | 原則 | 說明 | 影響 |
|---|
| AP-01 | 關注點分離 | 各層各司其職，避免跨層耦合 | 採用分層架構 |
| AP-02 | 設定外部化 | 應用程式設定不寫死於程式碼中 | 使用環境變數 / Config Server |
| AP-03 | 安全設計 | 預設安全，最小權限原則 | 所有 API 需認證授權 |
2.3 架構風格選擇#
| 項目 | 選擇 | 理由 |
|---|
| 整體架構風格 | 模組化單體（Modular Monolith） | 團隊規模 5 人，微服務複雜度過高 |
| 通訊模式 | 同步 REST + 非同步 Event（混合） | 一般操作同步；薪資計算等耗時作業非同步 |
| 資料管理 | 共用資料庫，邏輯 Schema 分離 | 初期簡化，保留未來拆分空間 |
3. 架構利害關係人與關注點#
📝 範本#
3.1 利害關係人識別#
| 利害關係人 | 角色 | 架構關注點 |
|---|
| {姓名/群組} | {角色} | {關注的品質屬性或架構面向} |
3.2 關注點矩陣#
| 關注點 | 描述 | 相關利害關係人 | 對應視圖 |
|---|
| {關注點} | {描述} | {人員} | {視圖名稱} |
📖 使用說明#
- 依據 ISO/IEC/IEEE 42010 第 5.2 節，架構描述必須識別利害關係人與其關注點
- 每個關注點（Concern）應對應到至少一個架構視圖來回應
- 關注點類型包含：功能性、可靠性、效能、安全性、可維護性、可部署性
💡 範例#
| 利害關係人 | 角色 | 架構關注點 |
|---|
| 開發團隊 | 開發工程師 | 模組結構、技術堆疊、開發規範 |
| 維運團隊 | SRE | 部署方式、監控、可觀測性 |
| 資安長 | CISO | 認證授權、資料保護、合規性 |
| 專案經理 | PM | 時程可行性、技術風險 |
| 終端使用者 | 員工 | 效能、可用性、易用性 |
4. 架構觀點定義#
📝 範本#
依據 ISO/IEC/IEEE 42010，本文件採用以下架構觀點（Viewpoints）：
| 觀點名稱 | 對應視圖 | 模型種類 | 回應的關注點 |
|---|
| Logical Viewpoint | 邏輯視圖 | Component Diagram, Class Diagram | 功能分解、模組職責 |
| Development Viewpoint | 開發視圖 | Package Diagram, Layer Diagram | 程式碼組織、技術堆疊 |
| Deployment Viewpoint | 部署視圖 | Deployment Diagram, Infra Diagram | 執行環境、網路拓撲 |
| Process Viewpoint | 流程視圖 | Sequence Diagram, Activity Diagram | 並行處理、資料流 |
| Data Viewpoint | 資料架構視圖 | ER Diagram, Data Flow Diagram | 資料模型、資料治理 |
📖 使用說明#
- ISO/IEC/IEEE 42010 不規定特定觀點集合，但建議參考 Kruchten 4+1 View Model
- 每個觀點（Viewpoint）定義了用來建立視圖的建模方法與表示法
- 可依專案需要增減觀點（如加入 Security Viewpoint）
💡 範例#
本系統架構描述採用 Kruchten 4+1 模型 + 資料視圖，共 5 個架構視圖：
- 邏輯視圖：以 Component Diagram 呈現主要模組與其互動
- 開發視圖：以 Package Diagram 呈現程式碼結構與技術堆疊
- 部署視圖：以雲端架構圖呈現 Azure 部署拓撲
- 流程視圖：以 Sequence Diagram 呈現關鍵業務流程的處理序列
- 資料視圖：以 ER Diagram 呈現資料模型
5. 邏輯視圖（Logical View）#
📝 範本#
5.1 高階元件圖（High-Level Component Diagram）#
┌─────────────────────────────────────────────────┐
│ Presentation Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web App │ │Mobile App│ │ Admin UI │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼──────────────┼──────────────┼───────────┘
│ │ │
┌───────┼──────────────┼──────────────┼───────────┐
│ ▼ ▼ ▼ │
│ Application Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Module A │ │Module B │ │Module C │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼──────────────┼──────────────┼───────────┘
│ │ │
┌───────┼──────────────┼──────────────┼───────────┐
│ ▼ ▼ ▼ │
│ Domain Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Domain A │ │Domain B │ │Domain C │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼──────────────┼──────────────┼───────────┘
│ │ │
┌───────┼──────────────┼──────────────┼───────────┐
│ ▼ ▼ ▼ │
│ Infrastructure Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Repository│ │ External │ │ Infra │ │
│ │ Impl │ │ Client │ │ Service │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────┘
5.2 元件職責說明#
| 元件名稱 | 職責描述 | 提供的介面 | 依賴的元件 |
|---|
| {元件} | {職責} | {介面} | {依賴} |
5.3 模組互動關係#
| 來源模組 | 目標模組 | 互動方式 | 說明 |
|---|
| {來源} | {目標} | {REST / Event / 直接呼叫} | {互動目的} |
📖 使用說明#
- 邏輯視圖回應「系統提供什麼功能」與「模組如何分工」
- 使用 Component Diagram（UML）或 C4 Model Container Diagram
- 每個元件應有明確的單一職責（Single Responsibility）
- 依賴關係應遵循依賴反轉原則（DIP）：高層模組不依賴低層模組
💡 範例#
5.2 元件職責說明#
| 元件名稱 | 職責描述 | 提供的介面 | 依賴的元件 |
|---|
| LeaveModule | 處理假勤申請、審核、假額計算 | LeaveAPI | EmployeeModule, NotificationService |
| PayrollModule | 薪資計算、加班費、扣款處理 | PayrollAPI | LeaveModule, EmployeeModule |
| NotificationService | 統一發送 Email/Push 通知 | NotificationAPI | 外部 SMTP Server |
| EmployeeModule | 員工資料 CRUD、組織架構管理 | EmployeeAPI | AD 整合 |
6. 開發視圖（Development View）#
📝 範本#
6.1 技術堆疊（Technology Stack）#
| 層級 | 技術選擇 | 版本 | 選用理由 |
|---|
| Frontend | {框架} | {版本} | {理由} |
| Backend | {框架} | {版本} | {理由} |
| Database | {資料庫} | {版本} | {理由} |
| Cache | {快取} | {版本} | {理由} |
| Message Queue | {MQ} | {版本} | {理由} |
| Container | {容器技術} | {版本} | {理由} |
6.2 專案結構（Project Structure）#
{project-name}/
├── src/
│ ├── {module-a}/
│ │ ├── controller/
│ │ ├── service/
│ │ ├── repository/
│ │ └── model/
│ ├── {module-b}/
│ └── shared/
├── tests/
├── docs/
├── deploy/
└── scripts/
6.3 分層規範#
| 層級 | 職責 | 允許依賴 | 禁止依賴 |
|---|
| Controller | 接收請求、參數驗證、回應轉換 | Service | Repository, External |
| Service | 業務邏輯、交易管理 | Repository, Domain | Controller |
| Repository | 資料存取封裝 | Domain, DB | Service, Controller |
| Domain | 領域模型、業務規則 | 無 | 其他所有層 |
📖 使用說明#
- 開發視圖回應「程式碼如何組織」與「開發者如何分工」
- 技術堆疊選擇需記錄理由，便於後續技術債評估
- 分層規範明確定義依賴方向，避免循環依賴
💡 範例#
6.1 技術堆疊#
| 層級 | 技術選擇 | 版本 | 選用理由 |
|---|
| Frontend | Vue.js + Vuetify | 3.4 | 團隊熟悉、元件庫完整 |
| Backend | .NET 8 + ASP.NET Core | 8.0 | 公司標準、LTS 支援 |
| Database | PostgreSQL | 16 | 開源、JSON 支援佳 |
| Cache | Redis | 7.2 | Session 管理 + 快取 |
| Message Queue | RabbitMQ | 3.13 | 薪資批次計算用非同步處理 |
| Container | Docker + Kubernetes | 1.29 | 公司雲端平台標準 |
7. 部署視圖（Deployment View）#
📝 範本#
7.1 部署架構圖#
┌─────────── Azure Cloud ───────────────────────────┐
│ │
│ ┌─── AKS Cluster ───────────────────────────┐ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ App Pod│ │ App Pod│ │Worker │ │ │
│ │ │(x3) │ │(x3) │ │Pod(x2) │ │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Azure DB │ │ Redis │ │ Blob │ │
│ │for PgSQL │ │ Cache │ │ Storage │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────────────────────────────────────┘
7.2 環境規劃#
| 環境 | 用途 | 規格 | 存取控制 |
|---|
| DEV | 開發測試 | {規格} | 開發團隊 |
| SIT | 整合測試 | {規格} | 開發 + 測試團隊 |
| UAT | 使用者驗收 | {規格} | 業務 + 測試團隊 |
| PROD | 正式環境 | {規格} | 維運團隊（受控） |
7.3 網路架構#
| 區域 | 網段 | 開放端口 | 說明 |
|---|
| {區域} | {CIDR} | {Port} | {用途} |
📖 使用說明#
- 部署視圖回應「系統在哪裡運行」與「基礎設施如何配置」
- 需包含所有環境（DEV/SIT/UAT/PROD）的規劃
- 網路架構需配合資安政策，定義防火牆規則與網段隔離
💡 範例#
7.2 環境規劃#
| 環境 | 用途 | 規格 | 存取控制 |
|---|
| DEV | 開發測試 | AKS 2 nodes (B2s) / PgSQL Basic | 開發團隊 VPN |
| SIT | 整合測試 | AKS 3 nodes (D2s_v3) / PgSQL GP | 開發 + QA VPN |
| UAT | 使用者驗收 | 同 PROD 規格 | 業務 + QA（受控網段） |
| PROD | 正式環境 | AKS 3 nodes (D4s_v3) / PgSQL GP HA | 僅維運團隊 |
8. 流程視圖（Process View）#
📝 範本#
8.1 關鍵流程序列圖#
流程名稱：{業務流程名稱}
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│Client│ │API GW│ │Service│ │ DB │
└──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
│ Request │ │ │
│────────────>│ Validate │ │
│ │─────────────>│ Query │
│ │ │─────────────>│
│ │ │ Result │
│ │ │<─────────────│
│ │ Response │ │
│ │<─────────────│ │
│ Response │ │ │
│<────────────│ │ │
8.2 非同步處理流程#
| 觸發事件 | 處理服務 | 處理邏輯 | 完成回調 |
|---|
| {事件} | {服務} | {邏輯描述} | {通知方式} |
8.3 並行與同步機制#
| 場景 | 機制 | 說明 |
|---|
| {場景} | {Lock / Queue / Saga} | {實作策略} |
📖 使用說明#
- 流程視圖回應「系統如何處理請求」與「並行行為如何協調」
- 使用 Sequence Diagram（UML）描述主要業務流程的互動序列
- 需特別關注非同步處理、分散式交易、競態條件（Race Condition）
💡 範例#
8.2 非同步處理流程#
| 觸發事件 | 處理服務 | 處理邏輯 | 完成回調 |
|---|
| 月薪計算啟動 | PayrollWorker | 逐筆計算員工薪資（底薪+加班-扣款） | 寫入 DB + 發送完成通知 |
| 請假審核通過 | LeaveService | 扣除假額、更新出勤紀錄 | Email 通知申請人 |
9. 資料架構視圖（Data View）#
📝 範本#
9.1 概念資料模型（Conceptual Data Model）#
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Employee │1────N│ Leave │ │ Payroll │
│ │ │ Record │ │ Record │
└──────────┘ └──────────┘ └──────────┘
│1 │N
│ │
└──────────────── 1 ──────────────────┘
9.2 資料儲存策略#
| 資料類型 | 儲存方式 | 技術選擇 | 理由 |
|---|
| 結構化業務資料 | RDBMS | {DB} | {理由} |
| 快取資料 | In-Memory | {Cache} | {理由} |
| 檔案/文件 | Object Storage | {Storage} | {理由} |
| 日誌資料 | Time-Series / Log Store | {Tool} | {理由} |
9.3 資料遷移策略#
| 來源系統 | 資料範圍 | 遷移方式 | 驗證方式 |
|---|
| {系統} | {資料} | {ETL / 雙寫 / Big Bang} | {驗證方法} |
📖 使用說明#
- 資料視圖回應「資料如何組織、儲存與流動」
- 概念模型不需到欄位層級（那是資料庫設計文件的範疇）
- 資料儲存策略需考量讀寫比例、一致性需求、資料量級
💡 範例#
9.2 資料儲存策略#
| 資料類型 | 儲存方式 | 技術選擇 | 理由 |
|---|
| 員工/假勤/薪資 | RDBMS | PostgreSQL 16 | ACID 事務、關聯查詢 |
| Session / 快取 | In-Memory | Redis 7.2 | 低延遲、TTL 管理 |
| 薪資單 PDF | Object Storage | Azure Blob | 大檔案、低成本 |
| 應用日誌 | Log Aggregation | ELK Stack | 全文搜尋、視覺化 |
10. 架構決策記錄（Architecture Decision Records）#
📝 範本#
ADR-{序號}：{決策標題}#
| 項目 | 內容 |
|---|
| 狀態 | 提案 / 已接受 / 已棄用 / 已取代 |
| 日期 | {YYYY-MM-DD} |
| 決策者 | {姓名} |
背景（Context）：
{描述面臨的問題或需要做出選擇的情境}
決策（Decision）：
我們決定採用 {選擇}。
理由（Rationale）：
替代方案（Alternatives Considered）：
| 方案 | 優點 | 缺點 | 不採用原因 |
|---|
| {方案 A} | {優點} | {缺點} | {原因} |
| {方案 B} | {優點} | {缺點} | {原因} |
影響（Consequences）：
📖 使用說明#
- ADR 格式參考 Michael Nygard 提出的 ADR 模式
- 每個重要的架構決策都應記錄，不論最終選擇為何
- ADR 一旦「已接受」不修改，若需變更則建立新 ADR 並標記舊的為「已取代」
- ADR 幫助後續維護人員理解「為什麼這樣設計」
💡 範例#
ADR-001：後端框架選擇 .NET 8#
| 項目 | 內容 |
|---|
| 狀態 | 已接受 |
| 日期 | 2026-03-15 |
| 決策者 | 陳建築（架構師） |
背景： 需選擇後端開發框架，團隊有 .NET 與 Java 經驗。
決策： 採用 .NET 8 + ASP.NET Core。
理由：
- 團隊 5 人中 4 人有 .NET 經驗
- .NET 8 為 LTS 版本，支援至 2029 年
- 公司已有 Visual Studio Enterprise 授權
替代方案：
| 方案 | 優點 | 缺點 | 不採用原因 |
|---|
| Java 21 + Spring Boot 3 | 生態系完整、跨平台 | 團隊需學習成本 | 時程限制不允許 |
| Node.js + NestJS | 前後端統一語言 | 企業級功能需自建 | 效能與型別安全疑慮 |
11. 品質屬性與戰術#
📝 範本#
11.1 品質屬性場景（Quality Attribute Scenarios）#
| 品質屬性 | 刺激來源 | 刺激 | 環境 | 回應 | 回應衡量 |
|---|
| 效能 | 使用者 | {操作} | {條件} | {系統回應} | {指標} |
| 可用性 | {來源} | {事件} | {條件} | {系統回應} | {指標} |
| 安全性 | {來源} | {威脅} | {條件} | {系統回應} | {指標} |
11.2 架構戰術（Architecture Tactics）#
| 品質屬性 | 戰術名稱 | 實作方式 |
|---|
| 效能 | Caching | {具體實作} |
| 可用性 | Redundancy | {具體實作} |
| 可修改性 | Encapsulation | {具體實作} |
| 安全性 | Authentication | {具體實作} |
📖 使用說明#
- 品質屬性場景（QAS）格式遵循 SEI 的六部分場景結構
- 架構戰術（Tactics）是達成品質屬性的設計手段
- 每個非功能性需求（來自 FRD 第 6 章）都應有對應的架構戰術
💡 範例#
11.1 品質屬性場景#
| 品質屬性 | 刺激來源 | 刺激 | 環境 | 回應 | 回應衡量 |
|---|
| 效能 | 500 位使用者 | 同時查詢假勤記錄 | 正常營運 | 系統回應查詢結果 | P95 ≤ 2 秒 |
| 可用性 | Azure | VM 故障 | 正常營運 | 自動故障轉移 | RTO ≤ 5 分鐘 |
| 安全性 | 攻擊者 | SQL Injection | 正常營運 | 拒絕惡意請求 | 0 筆資料外洩 |
12. 安全架構#
📝 範本#
12.1 認證與授權#
| 項目 | 設計 |
|---|
| 認證機制 | {OAuth 2.0 / SAML / OIDC} |
| 授權模型 | {RBAC / ABAC} |
| Session 管理 | {JWT / Server-side Session} |
| Token 有效期 | Access: {時間} / Refresh: {時間} |
12.2 資料保護#
| 保護對象 | 傳輸加密 | 靜態加密 | 存取控制 |
|---|
| {對象} | {方式} | {方式} | {機制} |
12.3 安全監控#
📖 使用說明#
- 安全架構需涵蓋：身份驗證、授權、資料保護、稽核日誌、安全監控
- 參考 OWASP Application Security Verification Standard (ASVS)
- 敏感資料（如身分證字號）需明確定義加密與遮罩策略
💡 範例#
12.1 認證與授權#
| 項目 | 設計 |
|---|
| 認證機制 | Azure AD B2C + OIDC（整合公司 AD） |
| 授權模型 | RBAC：Admin / HR_Staff / Manager / Employee |
| Session 管理 | JWT（存於 HttpOnly Secure Cookie） |
| Token 有效期 | Access: 15 分鐘 / Refresh: 7 天 |
13. 附錄#
📝 範本#
13.1 參考文件#
13.2 技術 POC 結果#
| POC 項目 | 結論 | 相關 ADR |
|---|
| {驗證項目} | {結論} | ADR-{xxx} |
13.3 術語表#
📖 使用說明#
- 附錄收錄支持性資料，不作為正文但提供佐證
- POC 結果記錄關鍵技術驗證的結論，支持架構決策
💡 範例#
13.2 技術 POC 結果#
| POC 項目 | 結論 | 相關 ADR |
|---|
| PostgreSQL vs SQL Server 效能比較 | 在 500 concurrent 下效能相當，PgSQL 授權成本更低 | ADR-002 |
| Redis Cluster vs Single Node | 目前規模 Single Node 足夠，保留未來擴展空間 | ADR-003 |
📌 範本使用注意事項
- 本範本依據 ISO/IEC/IEEE 42010:2022 標準結構編製
- 視圖數量可依專案規模增減，但邏輯視圖與部署視圖為核心必備
- 架構決策記錄（ADR）建議獨立管理，可使用 Git 版控
- SAD 應在設計階段初期建立，並隨開發過程持續演進
- 本文件為設計文件，不等同於實作細節（如詳細的 DB Schema、API 規格另有專屬文件）