摘要

前面兩篇介紹了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工程架構已經過時

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

相關推薦