可落地的DDD(3)-如何利用DDD進行微服務的劃分

摘要

前面兩篇介紹了DDD的目標管理、DDD的工程結構調整。這篇討論微服務的劃分。微服務是目先後端比較流行的架構體系了，那麼如何作好一個微服務的劃分？一個微服務的粒度應該是多大呢？這篇主要介紹如何結合DDD進行領域劃分。

工程結構代碼

上篇介紹了可落地的DDD的(2)-爲何說MVC工程架構已通過時
不少朋友留言說，有沒有sample code，要否則太溼了，不是很明白。這裏寫了個sample。

就以一個博客網站爲例
page1:博客列表頁： 展現全部用戶發表的博客

page2: 我的介紹頁：有我的簡介和博客列表

page3：博客詳情頁.

不一樣的業務展現的用戶/博客的字段不一致

建模

後期應該會有用戶和博客交互的需求。這期只有用戶建立博客這層關聯關係。

MVC架構

使用mvc模式寫出來的代碼，就是一路到底。
具體代碼見mvc-structure

DDD

使用DDD寫出來的工程結構就是，blog和user的交互只有一個地方，OpenXXXService
具體代碼見DDD structure

MVC VS DDD

從兩張依賴圖能夠看出，DDD的依賴圖清晰了，user和blog這兩個領域之間的交互變的清晰了，user這個領域不用管blog領域發生了什麼變動。只依賴OpenBlogService，而MVC模式呢，user和blog之間的交互太多了，若是再增長其餘功能，這些模塊之間就是夠籌交錯，理不清楚。

不一樣領域之間的交互多了，意味着一旦發生變動，須要修改邏輯了，那麼須要修改的地方就是幾何倍數的相關類。

好比業務發生了變動，統計【我的中心】的博客計數是用戶已發表的文章。而這個已發表的可能隨着業務的發展，包含多重含義

1. 用戶寫完了，對外開放了，
2. 運營審覈經過
3. 博客未被軟刪除的。
   這些邏輯都會影響相關的查詢，而這些邏輯的實現可能在數據庫層面作，可能在redis中作，或者其餘的方式。以MVC的寫法，須要的須要修改的地方不少，以DDD的方式，無論這個邏輯怎麼變，其餘領域不須要知道，只有blog領域知道，只用更改blog領域的代碼。

微服務劃分

第一版

肯定了以DDD做爲咱們領域劃分的指導原則後，咱們首先按照領域對咱們的業務進行了全面的分析，區分出哪些領域。而後按照以下標準進行了微服務的拆分

1. 一個領域一個服務的規則去拆分，
2. 同時爲了保證領域的純潔性，咱們區分了領域服務，和前臺服務。領域服務就是領域邏輯，不直接對前端暴露。前臺服務組裝各個領域服務，暴露給前端。
3. 同時爲了保持擴展，咱們預留了一個微服務做爲服務孵化器。對於領域不清晰的（好比大部分的新的業務），放在這個服務裏面孵化，而後等領域足夠大的時候再拆分出去。

以下圖

前臺應用：
pc: pc端的頁面展現
mobile: 移動端的頁面展現
mini：小程序的頁面展現

領域服務：
blog: 博客領域
user: 用戶領域
growth: 領域孵化器

按照這樣的標準去拆分後，一段時間後，不少問題暴露了。

• 服務熱點問題
  咱們是一個新的業務，在業務迭代的過程當中，大部分新需求都是領域不清晰，不知道能不能迭代下去的。因此按照以前的標準，都往growth服務裏面去寫代碼，這樣致使幾乎團隊裏面的全部的人都在開發這一個項目，失去了拆分微服務的意義。

• 服務依賴太嚴重
  不管寫什麼需求，都須要寫多個應用，領域服務1個，前臺若是有pc,須要在pc服務上開發，移動端要展現，要在mobile服務開發。服務之間的調用須要寫rpc client接口，須要發版本，由於同時開發的人多，常常發生版本混亂，依賴問題。服務上線也很頭疼，改一個小需求，須要部署多個服務。微服務一個很重要的點是去耦合，可獨立部署。多了一層UI層做爲微服務顯然不是很合適。

• 領域劃分有問題
  一個領域一個服務，粒度過小，有些東西不知道放在哪一個服務裏面，好比用戶收藏博客，是放在用戶服務裏面，仍是放在博客領域呢。

如何解決

不拆分單體應用不知道，一拆分問題一大堆。那麼咱們是怎麼解決的呢？下期再見。

相關閱讀
可落地的DDD(1)-目標討論
可落地的DDD的(2)-爲何說MVC工程架構已通過時

關注【方丈的寺院】，第一時間收到文章的更新，與方丈一塊兒開始技術修行之路