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

方丈發表於2019-06-02

摘要

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

微服務劃分

問題分析

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

一個領域一個服務的規則去拆分，

同時為了保證領域的純潔性，我們區分了領域服務，和前臺服務。領域服務就是領域邏輯，不直接對前端暴露。前臺服務組裝各個領域服務，暴露給前端。

同時為了保持擴充套件，我們預留了一個微服務作為服務孵化器。對於領域不清晰的（比如大部分的新的業務），放在這個服務裡面孵化，然後等領域足夠大的時候再拆分出去。

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

服務熱點問題我們是一個新的業務，在業務迭代的過程中，大部分新需求都是領域不清晰，不知道能不能迭代下去的。所以按照之前的標準，都往growth服務裡面去寫程式碼，這樣導致幾乎團隊裡面的所有的人都在開發這一個專案，失去了拆分微服務的意義。

服務依賴太嚴重無論寫什麼需求，都需要寫多個應用，領域服務1個，前臺如果有pc,需要在pc服務上開發，移動端要展示，要在mobile服務開發。服務之間的呼叫需要寫rpc client介面，需要發版本，因為同時開發的人多，經常發生版本混亂，依賴問題。服務上線也很頭疼，改一個小需求，需要部署多個服務。微服務一個很重要的點是去耦合，可獨立部署。多了一層UI層作為微服務顯然不是很合適。

領域劃分問題一個領域一個服務，粒度太小，有些東西不知道放在哪個服務裡面，比如使用者收藏部落格，是放在使用者服務裡面，還是放在部落格領域呢。

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

服務邊界不清晰

微服務的邊界不清晰，起因肯定是標準定義的不夠準確
服務之間依賴多了

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

解決手法

為了解決以上問題，我們反思了下我們的劃分標準，組內進行了深入的討論。一致覺得是因為我們為了推行DDD，在沒有深入思考的情況下，過早的進行了大面積的微服務拆分。導致了諸多的問題。雖然這麼做在當時的情況下，是最優的解決方案，但是帶來的問題也很突出。那什麼時候才是進行微服務拆分的最好時機呢? 因為理論學習、認知始終都沒有盡頭，只有實踐才能出真知。我們沒有糾結在過去的錯誤之中，而是重新讀取了DDD的理論。這一次有了不一樣的思考。

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

於是我們又重新梳理了一遍我們的整體業務

前臺功能

把我們所有端的前臺功能都梳理一遍，畫成圖

業務架構全景

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

劃分出上下文

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

非常抱歉了，涉及敏感資訊，這裡不能貼圖,如果覺得太抽象不好理解，請參考DDD落地：業務分析師和架構師的完美結對

新的微服務劃分標準

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

確定以限界上下文為微服務劃分的標準

限界上下文的劃分很難，但是必須要做。限界上下文不是憑空造出來的，而是從一個實體關聯關係、與業務人員溝通出來的。
服務的演進是以限界上下文作為單元進行演進的

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