摘要

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

微服務划分

問題分析

上篇介紹過我們一開始的服務划分標准

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

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

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

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

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

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

領域划分問題
一個領域一個服務，粒度太小，有些東西不知道放在哪個服務里面，比如用戶收藏博客，是放在用戶服務里面，還是放在博客領域呢。

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

服務邊界不清晰

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

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

解決手法

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

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

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

前台功能

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

業務架構全景

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

划分出上下文

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

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

新的微服務划分標准

我們提出了一種新的微服務划分標准

確定以限界上下文為微服務划分的標准

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

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