摘要
前面兩篇介紹了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之間的交互太多了，如果再增加其他功能，這些模塊之間就是夠籌交錯，理不清楚。
不同領域之間的交互多了，意味着一旦發生變更，需要修改邏輯了，那么需要修改的地方就是幾何倍數的相關類。
比如業務發生了變更，統計【個人中心】的博客計數是用戶已發表的文章。而這個已發表的可能隨着業務的發展，包含多重含義
- 用戶寫完了，對外開放了，
- 運營審核通過
- 博客未被軟刪除的。
這些邏輯都會影響相關的查詢，而這些邏輯的實現可能在數據庫層面做，可能在redis中做，或者其他的方式。以MVC的寫法，需要的需要修改的地方很多，以DDD的方式，不管這個邏輯怎么變，其他領域不需要知道，只有blog領域知道，只用更改blog領域的代碼。
微服務划分
初版
確定了以DDD作為我們領域划分的指導原則后，我們首先按照領域對我們的業務進行了全面的分析，區分出哪些領域。然后按照如下標准進行了微服務的拆分
- 一個領域一個服務的規則去拆分，
- 同時為了保證領域的純潔性，我們區分了領域服務，和前台服務。領域服務就是領域邏輯，不直接對前端暴露。前台服務組裝各個領域服務，暴露給前端。
- 同時為了保持擴展，我們預留了一個微服務作為服務孵化器。對於領域不清晰的（比如大部分的新的業務），放在這個服務里面孵化，然后等領域足夠大的時候再拆分出去。
如下圖
前台應用：
pc: pc端的頁面展示
mobile: 移動端的頁面展示
mini：小程序的頁面展示
領域服務：
blog: 博客領域
user: 用戶領域
growth: 領域孵化器
按照這樣的標准去拆分后，一段時間后，很多問題暴露了。
-
服務熱點問題
我們是一個新的業務，在業務迭代的過程中，大部分新需求都是領域不清晰，不知道能不能迭代下去的。所以按照之前的標准，都往growth服務里面去寫代碼，這樣導致幾乎團隊里面的所有的人都在開發這一個項目，失去了拆分微服務的意義。 -
服務依賴太嚴重
無論寫什么需求，都需要寫多個應用，領域服務1個，前台如果有pc,需要在pc服務上開發，移動端要展示，要在mobile服務開發。服務之間的調用需要寫rpc client接口，需要發版本，因為同時開發的人多，經常發生版本混亂，依賴問題。服務上線也很頭疼，改一個小需求，需要部署多個服務。微服務一個很重要的點是去耦合，可獨立部署。多了一層UI層作為微服務顯然不是很合適。 -
領域划分有問題
一個領域一個服務，粒度太小，有些東西不知道放在哪個服務里面，比如用戶收藏博客，是放在用戶服務里面，還是放在博客領域呢。
如何解決
不拆分單體應用不知道，一拆分問題一大堆。那么我們是怎么解決的呢？下期再見。
相關閱讀
可落地的DDD(1)-目標討論
可落地的DDD的(2)-為什么說MVC工程架構已經過時
關注【方丈的寺院】，第一時間收到文章的更新，與方丈一起開始技術修行之路
