參考資料  

三個步驟：
  1. 辨識系統操作
  2. 辨識服務
  3. 定義服務的 API 與協作方式

步驟一：辨識系統操作
  1. 建立高階的 domain model
  2. 定義系統操作



步驟二：辨識服務
  • 根據業務能力來定義服務
  • 依照 domain-driven design 的 subdomain 來組織服務
  • 圍繞業務概念而非技術概念來組織服務

透過套用 Decompose by sub-domain pattern 來定義服務
拆解準則
  1. SINGLE RESPONSIBILITY PRINCIPLE：一個 class 應該只有一個改變的理由
  2. COMMON CLOSURE PRINCIPLE：同一個 package 中的 class 應該對同類型的變更一起封閉。影響 package 的變更會影響該 package 中的所有 class。（我們可以在建立 microservice 架構時套用 CCP，把因相同原因而變更的元件打包到同一個服務中。）

拆解應用程式為服務的障礙
  • 網路延遲
  • 同步通訊導致可用性降低
  • 跨服務的資料一致性維護
  • 取得一致的資料檢視
  • God class 阻礙拆解
God class
「God class 通常實作了應用程式中許多不同面向的商業邏輯。它通常有大量的欄位對應到一個有很多欄位的資料庫表。大多數應用程式至少有一個這樣的 class，每個都代表一個領域中的核心概念：銀行的帳戶、電商的訂單、保險的保單等等。」

定義服務 API
服務 API 操作的存在有兩個原因：
  • 有些操作對應到系統操作。它們被外部 client 呼叫，也可能被其他服務呼叫。
  • 其他操作是為了支援服務之間的協作。這些操作只被其他服務呼叫。
  1. 將系統操作指派給服務
  2. 決定支援服務間協作所需的 API





You May Also Enjoy