> 原文地址：https://microservices.io/patterns/decomposition/decompose-by-business-capability.html # 背景介紹 假設你在開發一個大型複雜的微服務架構的應用，微服務架構的目標是將程式設計成一組鬆耦合的微服務應用，通過持續交付與部署，加速軟體開發。  微服務架構通過兩種方式實現這一點： 1. 簡化測試，並且保證元件能夠獨立部署。 2. 小型的（6-10個人）且自治的團隊互相協作完成軟體開發，每個小團隊負責一個或多個微服務。 但是要想享受這些好處，必須將服務拆分好。微服務要足夠的小，以便由一個小團隊開發，並且這樣更加易於測試。面向物件設計(OOD)的一個重要的指導原則就是**單一職責原則**(SRP)。SRP 將類的職責定義為更改這個類的原因，並規定一個類應該只有一個更改的原因。可以將 SRP 應用於服務設計，來設計更加內聚的服務並實現一小部分**強相關的功能**。 拆分微服務，還需要以一種讓大多數新的和需要更改的需求隻影響單個服務的方式進行拆分。這是因為影響多個服務的更改需要跨多個團隊的協調，這會減緩開發速度。OOD 的另一個有用的原則是**共同封閉原則**(CCP)，它指出，由於同樣的原因而改變的類應該在同一個包中。這樣，當需求發生變化時，只需要修改少量的程式碼，理想情況下只有一個包需要改變。這種想法在設計服務時也是有指導意義的，它將有助於確保每個更改隻影響一個服務。 # 問題 如何將應用程式分解為微服務？ # 考慮因素 - 整體架構需要是**穩定的** - 微服務必須是**內聚**的，即每個微服務應該實現一小部分強相關的功能 - 微服務設計需要按照**共同封閉原則**，會一起更改的內容，需要打包成為一個微服務，以確保每次變化只會影響一個微服務。 - 微服務必須是**鬆散耦合**的。每個服務都是封裝其實現的API，可以在不影響客戶端的情況下更改實現。 - 微服務需要是**可測試的** - 每個微服務可以由一個**小團隊開發** - 每個擁有一個或多個微服務的團隊必須是自主的。團隊必須能夠**獨立開發和部署他們的服務**，減少與其他團隊的協作成本。 # 解決方案 定義與**業務功能相對應**的服務。**業務功能**是業務體系結構建模中的一個概念，一般是指一個為創造價值而做的事情。**業務功能**通常是作用於**業務物件**，例如： - **訂單管理**負責執行訂單相關操作 - **使用者管理**負責針對使用者的操作 # 舉例 一個線上商店通常包括下面的業務功能： - 產品目錄管理 - 庫存管理 - 訂單管理 - 交付管理 - … 設計對應於這些功能的微服務：  # 好處 這種模式有以下好處： - 穩定的體系結構，因為業務功能的劃分是相對穩定的。按照業務功能拆分微服務模組也會是穩定的，不會發生一會增加一個微服務，一會去掉一個微服務。 - 開發團隊是跨功能的、自主的，並且是圍繞著交付業務價值而不是技術特性而組織起來的。 - 微服務具有內聚性和鬆散耦合性。 # 問題 主要問題就是如何設計**業務功能**？需要理解業務才能設計好**業務功能**。一般業務功能是按照分析公司的目的、結構、業務流程和專業領域來設計的。通過**迭代流程**不斷改變與擴充套件業務功能邊界。一般可以從如下方面來開始設計**業務功能**： - 公司組織結構：公司組織設計就是按照業務功能進行設計的，組織內部的不同組可能對應於不同的業務功能組。 - 高層次領域模型：一般業務功能會被設計成針對於某些領域物件的一些操作或者服務。 # 相關模式 可選擇替代的另一種設計模式是**按子域拆分