在微服務架構的導入過程中，最困難卻也最關鍵的一步，往往不是 Kubernetes 要怎麼部署，也不是 CI/CD 怎麼落地，而是 「服務要怎麼拆」。如果服務邊界切錯了，後續的開發與維運會變成惡夢；但若邊界切得清晰、合理，整個系統就會具備「可理解、可維護、可擴展」的特質。

本文將從 服務拆分的起點 出發，帶你理解 什麼是服務邊界，如何透過 模組化與資訊隱藏 來定義邊界，並進一步探討 內聚與耦合 的原則。最後，將介紹常見的服務拆分方式，讓你在實務中有一份清晰的設計指南。

微服務設計從哪裡開始-服務拆分

當你第一次嘗試設計微服務架構時，可能會直覺地問自己：「那我應該要從資料庫切起嗎？還是從 API 功能開始劃分？」
其實，服務拆分的出發點，應該是***「業務邏輯與模組化分解」***。

微服務是一種模組化設計的實現：

• 在單體應用中，我們習慣把功能模組化，例如：會員模組、訂單模組、付款模組。
• 在微服務中，這些模組被進一步「獨立部署、獨立維運」，成為一個個微服務。

因此，如果你能夠正確地切模組，你其實就已經具備了做微服務架構的基礎。微服務只是在模組化的基礎上，將「開發邏輯」與「運行邏輯」結合，進一步做邊界封裝。

服務邊界的判斷依據：封裝與資訊隱藏

資訊隱藏 (Information Hiding)

資訊隱藏 是軟體工程中最經典的設計概念之一。Parnas 在 1972 年提出的模組化理論就指出：

把可能變動的設計決策，封裝在模組的內部，並確保介面不會暴露這些細節

這句話放在微服務設計中同樣適用。

• 好的服務邊界 = 對外只暴露需要的能力，並將內部可能變動的部分（演算法、資料存取、流程細節）完全隱藏。
• 不好的服務邊界 = 過度暴露內部設計，導致其他服務高度依賴，一旦改動就會牽連整個系統。

舉例來說：

• 會員服務只需對外提供「驗證會員」與「查詢會員基本資料」的 API，至於會員的積分計算規則、等級演算法，應該全部隱藏在內部。
• 訂單服務只需對外暴露「建立訂單」、「查詢訂單狀態」，但內部的流程控制（庫存檢查、支付確認）不應直接暴露給其他服務操作。

對介面程式設計 (Programming to an Interface)

另一個關鍵原則是

「programming to an interface, not an implementation」

這意味著服務之間應該基於協議 / API 合約進行互動，而非依賴內部實作。如此一來，當實作更換（例如資料庫換成另一種、演算法改進）時，只要介面不變，其他服務完全不受影響。

模組化設計的核心：內聚與耦合

在判斷服務邊界時，最常見的兩個評估指標是：內聚性 (Cohesion) 與 耦合度 (Coupling)。

內聚性 (Cohesion)

內聚性代表模組內部的功能是否彼此相關，是否應該放在一起。

• 高內聚：相同概念、相同生命周期、常常一起變動的功能應該放在同一個服務。
• 低內聚：功能彼此無關卻被強行放在一起，會導致服務變得「四不像」。

範例：
-「訂單建立」與「訂單取消」應該放在同一個服務（因為生命周期一致）。
-「會員登入」與「訂單建立」不應該放在同一個服務（兩者概念不同，業務邏輯不相關）。

耦合度 (Coupling)

耦合度描述模組之間的依賴關係。

• 高耦合：一個服務的修改會影響到其他服務（例如：需要直接訪問其他服務的資料庫）。
• 低耦合：服務之間僅透過明確的 API 介面互動，修改內部邏輯時不影響其他服務。

若內聚性強而耦合度低，則結構式穩定的。

微服務是圍繞業務領域的可部署元件

綜合以上原則，我們可以下這樣的定義：
微服務是圍繞業務領域（Business Domain）構建，並且能夠獨立部署的元件。

• 「圍繞業務領域」：服務邊界的劃分應以業務能力或業務子領域為基礎，而不是技術分層。
  -「可獨立部署」：一個微服務必須能單獨上線、單獨演進，而不需要其他服務同步改動。

常見的服務邊界模式 (Service Boundaries Patterns)

在實務設計中，有幾種常見的 服務邊界劃分模式，可以作為設計時的參考。

Decompose by Business Capability

• 根據企業的「業務能力」來拆分服務。
• 例如：電商系統可分為「會員管理」「商品管理」「訂單管理」「支付管理」。
• 優點：與業務直接對齊，溝通成本低。
• 缺點：可能出現「大服務」或「過於籠統」的問題，需要再細化。

Decompose by Subdomain (DDD Subdomain)

• 以 領域驅動設計 (DDD) 的子領域為依據。
• 例如：在「訂單」領域中，可能拆分成「訂單核心處理」「訂單付款」「訂單配送」。
• 優點：有理論支撐，結構更清晰。
• 缺點：需要較深的 DDD 知識。

Self-contained Service

• 設計服務時，盡量讓它能 自給自足，不必同步等待其他服務回應。
• 例如：訂單服務在建立訂單時，不應同步等待「支付服務」完成，而應改為事件驅動（下單 → 發送事件 → 支付服務異步處理）。
• 優點：提升可靠性，降低同步耦合。
• 缺點：需要事件機制與最終一致性處理。

這可以檢視 「微服務是圍繞業務領域（Business Domain）構建，並且能夠獨立部署的元件」

Service per Team

• 每個團隊負責一個或一組服務，避免跨團隊的開發依賴。
• 優點：組織與架構對齊，團隊邊界即服務邊界。
• 缺點：需要 DevOps 能力支撐。

結語

服務邊界 是微服務設計中最基礎、也是最困難的問題。它融合了模組化、資訊隱藏、內聚/耦合等軟體工程經典概念，也需要結合業務領域的知識與組織結構的現實考量。

當你能熟練掌握這些原則，並靈活應用這些內容，你就具備了設計出「既符合業務邏輯、又能獨立演進」的微服務系統的能力。這，正是微服務能真正發揮價值的起點。