[翻譯]微服務設計模式 - 3. 按業務功能拆分模式

原文地址：https://microservices.io/patterns/decomposition/decompose-by-business-capability.html

背景介紹

假設你在開發一個大型複雜的微服務架構的應用，微服務架構的目標是將程序設計成一組鬆耦合的微服務應用，經過持續交付與部署，加速軟件開發。

微服務架構經過兩種方式實現這一點：

1. 簡化測試，而且保證組件可以獨立部署。
2. 小型的（6-10我的）且自治的團隊互相協做完成軟件開發，每一個小團隊負責一個或多個微服務。

可是要想享受這些好處，必須將服務拆分好。微服務要足夠的小，以便由一個小團隊開發，而且這樣更加易於測試。面向對象設計(OOD)的一個重要的指導原則就是單一職責原則(SRP)。SRP 將類的職責定義爲更改這個類的緣由，並規定一個類應該只有一個更改的緣由。能夠將 SRP 應用於服務設計，來設計更加內聚的服務並實現一小部分強相關的功能。

拆分微服務，還須要以一種讓大多數新的和須要更改的需求隻影響單個服務的方式進行拆分。這是由於影響多個服務的更改須要跨多個團隊的協調，這會減緩開發速度。OOD 的另外一個有用的原則是共同封閉原則(CCP)，它指出，因爲一樣的緣由而改變的類應該在同一個包中。這樣，當需求發生變化時，只須要修改少許的代碼，理想狀況下只有一個包須要改變。這種想法在設計服務時也是有指導意義的，它將有助於確保每一個更改隻影響一個服務。

問題

如何將應用程序分解爲微服務？

考慮因素

• 總體架構須要是穩定的
• 微服務必須是內聚的，即每一個微服務應該實現一小部分強相關的功能
• 微服務設計須要按照共同封閉原則，會一塊兒更改的內容，須要打包成爲一個微服務，以確保每次變化只會影響一個微服務。
• 微服務必須是鬆散耦合的。每一個服務都是封裝其實現的API，能夠在不影響客戶端的狀況下更改實現。
• 微服務須要是可測試的
• 每一個微服務能夠由一個小團隊開發
• 每一個擁有一個或多個微服務的團隊必須是自主的。團隊必須可以獨立開發和部署他們的服務，減小與其餘團隊的協做成本。

解決方案

定義與業務功能相對應的服務。業務功能是業務體系結構建模中的一個概念，通常是指一個爲創造價值而作的事情。業務功能一般是做用於業務對象，例如：

• 訂單管理負責執行訂單相關操做
• 用戶管理負責針對用戶的操做

舉例

一個線上商店一般包括下面的業務功能：

• 產品目錄管理
• 庫存管理
• 訂單管理
• 交付管理
• …

設計對應於這些功能的微服務：

好處

這種模式有如下好處：

• 穩定的體系結構，由於業務功能的劃分是相對穩定的。按照業務功能拆分微服務模塊也會是穩定的，不會發生一會增長一個微服務，一會去掉一個微服務。
• 開發團隊是跨功能的、自主的，而且是圍繞着交付業務價值而不是技術特性而組織起來的。
• 微服務具備內聚性和鬆散耦合性。

問題

主要問題就是如何設計業務功能？須要理解業務才能設計好業務功能。通常業務功能是按照分析公司的目的、結構、業務流程和專業領域來設計的。經過迭代流程不斷改變與擴展業務功能邊界。通常能夠從以下方面來開始設計業務功能：

• 公司組織結構：公司組織設計就是按照業務功能進行設計的，組織內部的不一樣組可能對應於不一樣的業務功能組。
• 高層次領域模型：通常業務功能會被設計成針對於某些領域對象的一些操做或者服務。

相關模式

可選擇替代的另外一種設計模式是按子域拆分模式