43 lines
1.5 KiB
Markdown
43 lines
1.5 KiB
Markdown
|
|
# 系統分解 (System Decomposition) 知識合約指南
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
`system-decomposition` 是知識合約,用來提供將系統拆分為服務或模組的原則。包含邊界定義、資料所有權與依賴方向。供 `design-architecture` 在設計 Service Boundaries 時參考。
|
|||
|
|
|
|||
|
|
## 核心原則
|
|||
|
|
- 每個服務或模組必須有單一、明確的職責
|
|||
|
|
- 資料所有權必須明確:每筆資料只屬於一個服務
|
|||
|
|
- 依賴必須單向流動;嚴禁循環依賴
|
|||
|
|
- 邊界必須環繞領域職責繪製,而非技術分層
|
|||
|
|
|
|||
|
|
## 設計重點
|
|||
|
|
### Modular Monolith vs Microservices
|
|||
|
|
- 選擇 Modular Monolith:團隊小、邊界仍在演化、部署簡單優先
|
|||
|
|
- 選擇 Microservices:個別服務有不同擴展需求、團隊擁有對齊、獨立部署是需求
|
|||
|
|
|
|||
|
|
### 領域邊界
|
|||
|
|
- 一起變化的實體
|
|||
|
|
- 內聚的業務規則
|
|||
|
|
- 一起存取的資料
|
|||
|
|
- 橫跨一致上下文的使用者工作流
|
|||
|
|
|
|||
|
|
好的邊界:高內聚、低外部耦合、可獨立理解、可獨立部署。
|
|||
|
|
|
|||
|
|
### 耦合 vs 內聚
|
|||
|
|
- 偏好邊界內高內聚
|
|||
|
|
- 最小化邊界間耦合
|
|||
|
|
- 透過明確合約(API、事件)溝通
|
|||
|
|
- 避免共享資料庫表
|
|||
|
|
|
|||
|
|
### 狀態所有權
|
|||
|
|
- 每筆狀態只有一個擁有者
|
|||
|
|
- 其他服務透過擁有者的 API 或事件存取
|
|||
|
|
- 嚴禁服務直接讀取另一服務的資料庫
|
|||
|
|
|
|||
|
|
## 知識合約職責
|
|||
|
|
- 提供系統分解的理論指引
|
|||
|
|
- 不替 PRD 做最終邊界決策
|
|||
|
|
|
|||
|
|
## 不應做的事
|
|||
|
|
- 不替系統定義特定服務邊界
|
|||
|
|
- 不假設 Microservices 適合所有場景
|
|||
|
|
- 不忽略領域邊界而以技術分層
|