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

摘要

在前面一篇介紹瞭如何經過DDD的思想，來調整單體服務內的工程結構，爲微服務的拆分作準備。同時介紹了咱們在進行微服務拆分的時候踩過的一些坑。
這篇介紹下咱們最終的方案，不必定對，歡迎留言討論。

微服務劃分

問題分析

上篇介紹過咱們一開始的服務劃分標準

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

實踐後有些典型的問題也比較突出

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

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

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

三個比較突出的問題，反應出的共性問題就是

• 服務邊界不清晰

  微服務的邊界不清晰，原由確定是標準定義的不夠準確

• 服務之間依賴多了

  微服務的一個重要特徵就是自治性，若是依賴的服務多了，那麼咱們就享受不到微服務帶來的好處，而只能感覺到微服務的壞處。

解決手法

爲了解決以上問題，咱們反思了下咱們的劃分標準，組內進行了深刻的討論。一致以爲是由於咱們爲了推行DDD，在沒有深刻思考的狀況下，過早的進行了大面積的微服務拆分。致使了諸多的問題。雖然這麼作在當時的狀況下，是最優的解決方案，可是帶來的問題也很突出。那何時纔是進行微服務拆分的最好時機呢?
由於理論學習、認知始終都沒有盡頭，只有實踐才能出真知。咱們沒有糾結在過去的錯誤之中，而是從新讀取了DDD的理論。這一次有了不同的思考。

DDD中有戰略設計，劃分領域，找出限界上下文，識別出核心域。而後有戰術設計，對領域進行建模，
聚合根、實體、值對象、領域服務、領域事件等。戰略設計一般就是指導思想，戰術設計是具體打法。咱們一開始認定要
先有指導思想，而後再有具體打法。如今發現咱們錯了，指導思想不是一蹴而就的，也不是不成不變的。在一開始沒有標準時，它必需要來源於實際打法中。
同時須要在實踐過程當中不斷總結，修正、完善指導思想。

因而咱們又從新梳理了一遍咱們的總體業務

前臺功能

把咱們全部端的前臺功能都梳理一遍，畫成圖

業務架構全景

根據前臺功能，進一步整理，抽象出業務架構全景

劃分出上下文

根據業務架構全景，在覈心域中創建出限界上下文，拆分微服務

很是抱歉了，涉及敏感信息，這裏不能貼圖,若是以爲太抽象很差理解，請參考DDD落地：業務分析師和架構師的完美結對

新的微服務劃分標準

咱們提出了一種新的微服務劃分標準

• 肯定以限界上下文爲微服務劃分的標準

  限界上下文的劃分很難，可是必需要作。限界上下文不是憑空造出來的，而是從一個實體關聯關係、與業務人員溝通出來的。

• 服務的演進是以限界上下文做爲單元進行演進的

  以前咱們拿一個微服務做爲領域孵化器，其實就是放棄了對業務的總體認知，和對新需求的業務思考。
  咱們的新業務不是一個新產品，所有推倒重來的。大多時候它仍是解決某類業務上的問題。只是採起的手段不同罷了。
  因此咱們須要挖掘其本質，將它放到現有的上下文中。每一個上下文一個微服務，對應一個開發owner,他負責這個領域內的事情。
  這樣每一個服務都有新的領域孵化。

舉例

以電商舉例，若是隻是一個創業公司，不可能都跟阿里巴巴同樣的架構，上百個服務。可是解決的問題電商領域能夠抽象出來。

限界上下文

分爲人、貨、場、交易幾個上下文。而後不斷的孵化，哪一部分是你業務的核心域，而後不斷的服務拆分，好比你也是一家作垂直電商的公司，這些基本的東西確定不該該是你的核心域，只能是支撐域，要否則你的業務確定發展不起來。

微服務的劃分

從限界上下文中抽出微服務，一個微服務中包含了多個領域。

另外咱們遺棄了以前的UI服務，全部微服務能夠直接和前臺交互，這樣能夠有效的減小服務的依賴。
只有當須要多個領域進行組合時，咱們才寫在一個新的【組合ui】服務裏面

另外限界上下文不是一層不變的，好比商品營銷，是一個領域，業務簡單時和商品的關聯性比較大，放在商品域。當你須要同時對店鋪作營銷，對用戶作營銷，顯然他不該該在商品上下文了，那麼能夠剝離出來，做爲一個獨立的限界上下文：營銷上下文。

相關閱讀

可落地的DDD(1)-目標討論

可落地的DDD的(2)-爲何說MVC工程架構已通過時

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

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