分解模式 - 按業務領域分解模式劃分微服務

本文說明如何經過業務領域分析和DDD將大型複雜的應用程序劃分爲一組微服務。

場景

使用微服務架構開發一個大型複雜的應用程序，咱們須要將應用程序細緻，合理地分解爲一組鬆散耦合的微服務。微服務架構的目標是經過實現持續交付/部署來加速軟件開發。

目標

• 架構必須穩定；
• 服務必須高內聚 - 服務應該實現一小組強相關的功能；
• 服務必須符合開閉原則 - 將一同變動的內容打包在一塊兒，以確保每一個更改僅影響一個服務；
• 服務必須鬆耦合 - 每一個服務均可以在不影響客戶端的狀況下更改實現；
• 服務應該是可測試的；
• 每項服務都小到足以由「兩個披薩」團隊開發，即一個6-10人的團隊；
• 負責一個或多個服務的每一個團隊必須是自治的 - 團隊可以在與其餘團隊儘可能少的協做下，來開發和部署他們的服務。

方法

經過領域驅動設計（DDD），設計與 子域 相對應的服務。DDD經過分析問題空間和業務邏輯，將應用程序定義爲域。域由多個子域組成。每一個子域對應於業務的不一樣部分。

子域可分爲如下幾類：

• 核心類 - 業務的關鍵差別化因素和應用程序中最有價值的部分；
• 支持類 - 與業務有關，但與差別化無關；這些能夠在內部實施或外包；
• 通用類 - 與業務無關，理想狀況下可使用現成的軟件實現。

例子

一個在線商店的子域包括：

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

相應的微服務架構中，每個子域將對應一個微服務。

優勢

• 因爲子域相對穩定，所以具備穩定的體系結構；
• 開發團隊能有效隔離業務邏輯和技術框架；
• 服務具備高內聚和鬆耦合。

問題

如何識別子域？
識別子域須要瞭解業務。經過分析業務及其組織結構來識別不一樣的專業領域，從而識別子域。這個過程一般須要不斷迭代。

識別子域的好思路是：

• 組織結構 - 組織內的不一樣分組或部門可能對應於不一樣子域；
• 高階域模型 - 子域一般具備關鍵域對象。

相關模式

微服務架構風格