28 lines
1.3 KiB
Markdown
28 lines
1.3 KiB
Markdown
|
|
# 架構模式 (Architecture Patterns) 知識合約指南
|
||
|
|
|
||
|
|
## 概述
|
||
|
|
`architecture-patterns` 是知識合約,用來提供架構模式選擇的原則與取決框架。涵蓋 Modular Monolith、Microservices、Layered、Clean、Hexagonal、Event-Driven、CQRS、Saga、Outbox 等模式。供 `design-architecture` 在選擇架構模式時參考。
|
||
|
|
|
||
|
|
## 核心原則
|
||
|
|
選擇模式唯一的原因是它解決了 PRD 中實際存在的問題。不要因為時尚或覺得以後可能需要就採用模式。
|
||
|
|
|
||
|
|
## 模式選項
|
||
|
|
- **Modular Monolith**:單一部署單元,內部有明確模組邊界
|
||
|
|
- **Microservices**:多個獨立部署服務,每個職責單一
|
||
|
|
- **Layered Architecture**:水平分層(展示層、業務層、資料層)
|
||
|
|
- **Clean Architecture**:以用例為中心,依賴反轉
|
||
|
|
- **Hexagonal Architecture**:透過埠與轉接器隔離商業邏輯
|
||
|
|
- **Event-Driven**:透過事件而非直接呼叫溝通
|
||
|
|
- **CQRS**:讀取模型與寫入模型分離
|
||
|
|
- **Saga Pattern**:跨服務分散式交易的補償機制
|
||
|
|
- **Outbox Pattern**:可靠事件發布的確保機制
|
||
|
|
|
||
|
|
## 知識合約職責
|
||
|
|
- 提供各模式的 Use When / Avoid When 判斷原則
|
||
|
|
- 說明各模式的 Trade-offs
|
||
|
|
- 不替 PRD 做最終模式選擇
|
||
|
|
|
||
|
|
## 不應做的事
|
||
|
|
- 不替系統選擇特定模式
|
||
|
|
- 不提供具體實作建議
|
||
|
|
- 不產生任何架構產出
|