隨著14年左右開(kāi)始，業(yè)界開(kāi)始流行微服務(wù)架構(gòu)，開(kāi)始是基于Dubbo的微服務(wù)，后面慢慢的Spring 開(kāi)源組織開(kāi)始發(fā)力，SpringBoot 和SpringCloud 相繼出來(lái)，越來(lái)越流行，特別是18年開(kāi)始，似乎SpringCloud 已經(jīng)成為項(xiàng)目開(kāi)發(fā)的標(biāo)配，有一種感覺(jué)如果你沒(méi)搞過(guò)SpringCloud，都不好意思和人打招呼。

本文不是探討SpringCloud，而是探討基于微服務(wù)的DDD實(shí)施，在以前單應(yīng)用流行于天下時(shí)，一個(gè)系統(tǒng)一個(gè)應(yīng)用，基本上也沒(méi)有什么服務(wù)的劃分，更談?wù)劜簧戏謳?kù)（不考慮性能因素）。所以那個(gè)年代，DDD 很多邏輯和概念都無(wú)法落地（DDD的方法論應(yīng)該是Evans于2004年提出），所以讓很多人認(rèn)為很專(zhuān)家，很概念，很不落地。但隨著微服務(wù)流行，慢慢的大家會(huì)意識(shí)到一個(gè)問(wèn)題：就是對(duì)于一個(gè)復(fù)雜的系統(tǒng)，需要實(shí)施微服務(wù)架構(gòu)時(shí)，如何劃分服務(wù)？

比如筆者比較熟悉的領(lǐng)域，支付清算行業(yè)，一般我們會(huì)規(guī)劃出這樣幾個(gè)微服務(wù)：收銀臺(tái)，交易中心，賬戶(hù)，用戶(hù)，商戶(hù)，對(duì)賬，清分，結(jié)算等等這些微服務(wù)。當(dāng)然這是筆者沉積了十幾年的經(jīng)驗(yàn)和同行交流學(xué)習(xí)得出來(lái)的經(jīng)驗(yàn)的劃分方法，但這個(gè)總感覺(jué)是從結(jié)果推過(guò)程，但當(dāng)我們面對(duì)一個(gè)全新的領(lǐng)域時(shí)或則經(jīng)驗(yàn)不足時(shí)，如何劃分了，這就有這非?；影俪龅姆址?，最終也因?yàn)榻?jīng)驗(yàn)的不足，而導(dǎo)致我們的系統(tǒng)微服務(wù)也是千奇百怪，我見(jiàn)過(guò)有在商戶(hù)服務(wù)里面做記賬的，也有在用戶(hù)服務(wù)中，涉及到電商交易的。實(shí)際上按照本人的理解，一個(gè)相對(duì)規(guī)范的微服務(wù)應(yīng)該是下面這個(gè)樣子：

而因?yàn)樵O(shè)計(jì)的不合理，劃分的拍腦袋，導(dǎo)致出現(xiàn)實(shí)際的樣子是這樣的：

上面這種微服務(wù)在我看來(lái)是一種偽微服務(wù)，為了微服務(wù)而誕生的微服務(wù)架構(gòu)。為什么，因?yàn)檫@里面他很多的微服務(wù)都是共用的一個(gè)數(shù)據(jù)庫(kù)，只是簡(jiǎn)單的做了一個(gè)服務(wù)層面的分布式，數(shù)據(jù)層面依然是邏輯共用的。這樣等于只是代碼分別放在了不同的地方而已，而且沒(méi)有任何約束，在這種架構(gòu)下你還會(huì)很容易的發(fā)現(xiàn)有其他諸多問(wèn)題：比如一個(gè)數(shù)據(jù)的更新邏輯，往往分布在多處（原因很多：事務(wù)，工程，素質(zhì)等等），我說(shuō)的多處是多處服務(wù)，那么對(duì)于這個(gè)數(shù)據(jù)依賴(lài)和耦合度也就和更多的服務(wù)相關(guān)，這樣的實(shí)際反而還不如一個(gè)單應(yīng)用來(lái)的直接和簡(jiǎn)單明了。比如訂單這個(gè)數(shù)據(jù)，我A服務(wù)能改，B服務(wù)也同樣能改呀，這樣在我看來(lái)就是一靠自覺(jué)，二靠運(yùn)氣的微服務(wù)架構(gòu)，因?yàn)槲覀兺菬o(wú)法通過(guò)這種架構(gòu)對(duì)代碼進(jìn)行合理的維護(hù)，甚至性能的提升。

所以市面上很多公司的所謂的微服務(wù)架構(gòu)其實(shí)只是技術(shù)上的分布式，而僅僅是為了滿(mǎn)足個(gè)別技術(shù)人員的技術(shù)提升的私心，這樣的架構(gòu)設(shè)計(jì)，也許只有當(dāng)事人才看得懂，業(yè)務(wù)和產(chǎn)品無(wú)法理解，為了微服務(wù)而微服務(wù)/具體為了業(yè)務(wù)，一個(gè)產(chǎn)品看得懂，業(yè)務(wù)瞧得明白，代碼邏輯清晰的微服務(wù)架構(gòu)系統(tǒng)其實(shí)是比較稀缺的。

那么DDD 在我看來(lái)就是可以解決這個(gè)問(wèn)題（通過(guò)建立領(lǐng)域模型再推導(dǎo)出微服務(wù)），這也是伴隨著微服務(wù)的流行，DDD為什么又死灰復(fù)燃了（貶義褒用）的根本原因。

在DDD的實(shí)施環(huán)節(jié)中，對(duì)于一個(gè)系統(tǒng)，開(kāi)始并不是劃分什么微服務(wù)，而是先組織一個(gè)活動(dòng)：事件風(fēng)暴

事件風(fēng)暴在我看來(lái)：第一需要組織相關(guān)的參與者，最后能邀請(qǐng)到該需求提出者，業(yè)務(wù)人員，產(chǎn)品設(shè)計(jì)人員，以及開(kāi)發(fā)代表（應(yīng)用架構(gòu)師），測(cè)試代表等等。

然后開(kāi)始事件風(fēng)暴：首先是用例收集和分析，再初步的進(jìn)行領(lǐng)域劃分，首先我要提到整個(gè)事件風(fēng)暴雖然有幾個(gè)步驟，但不是瀑布似的過(guò)程，而是迭代的反復(fù)進(jìn)行，不停的設(shè)計(jì)和修正，盡可能全面不遺漏地分解業(yè)務(wù)領(lǐng)域。

用例分析：就是通過(guò)一個(gè)個(gè)需求用例提出用戶(hù)使用場(chǎng)景和領(lǐng)域劃分（用戶(hù)不光指人類(lèi)）

下圖是筆者曾經(jīng)做出的用例分析圖一部分（補(bǔ)充：這個(gè)只是一部分圖，而且是事后在整理在一起的，在分析時(shí)，是一個(gè)思維發(fā)散的過(guò)程）

? ? ?用例分析第一步就找出復(fù)雜用例和長(zhǎng)用例，即調(diào)用關(guān)系復(fù)雜，業(yè)務(wù)鏈路較長(zhǎng)的用例，針對(duì)這類(lèi)型的用例，我們一般認(rèn)為，這樣的用例可以通過(guò)：事件傳遞等方式，將其拆分成小用例。比如用戶(hù)購(gòu)買(mǎi)東西支付成功，這個(gè)在需求提出的最開(kāi)始就是一個(gè)動(dòng)作，但伴隨業(yè)務(wù)的流轉(zhuǎn)，它需要經(jīng)歷支付處理過(guò)程，訂單處理過(guò)程，以及商品庫(kù)存處理過(guò)程，以及后續(xù)發(fā)貨等等過(guò)程。但我們經(jīng)過(guò)仔細(xì)的業(yè)務(wù)分析，會(huì)發(fā)現(xiàn)，這個(gè)用例完全是可以拆成支付用例，訂單狀態(tài)處理用例。商品處理用例，以及 發(fā)貨用例等等。那么這些用例間如何進(jìn)行串聯(lián)調(diào)用了，完全可以通過(guò)相應(yīng)的用例執(zhí)行結(jié)果通知的方式，將用例進(jìn)行相應(yīng)的串接。

? ? ? 通過(guò)上面的用例收集和分析過(guò)程，我們會(huì)發(fā)現(xiàn)一些用例在業(yè)務(wù)的上下文中，基本是可以劃為一類(lèi)：比如電商的 訂單處理，物流，支付系統(tǒng)的：對(duì)賬，結(jié)算，支付等等，其實(shí)這個(gè)就已經(jīng)初步出現(xiàn)了領(lǐng)域的劃分了（注意這還只是初步），然后我們可以在這些領(lǐng)域中，我們可以找尋其中的核心域和支撐域，以及通用域。發(fā)現(xiàn)整個(gè)系統(tǒng)的核心域，但核心域的劃分沒(méi)有絕對(duì)的公式，因?yàn)樯虡I(yè)模式的不同會(huì)導(dǎo)致核心域劃分結(jié)果的不同。有的公司核心域可能在客戶(hù)服務(wù)，有的可能在產(chǎn)品質(zhì)量，有的可能在物流。在公司領(lǐng)域細(xì)分、建立領(lǐng)域模型和系統(tǒng)建設(shè)時(shí)，我們就要結(jié)合公司戰(zhàn)略重點(diǎn)和商業(yè)模式，找到核心域了，且應(yīng)該重點(diǎn)關(guān)注核心域。

? ? ?雖然沒(méi)有公式，但如何找到核心域，依照我的經(jīng)驗(yàn)提出一個(gè)問(wèn)題：這個(gè)系統(tǒng)是通過(guò)什么東西提供了核心業(yè)務(wù)服務(wù)是什么？注意這個(gè)不是技術(shù)問(wèn)題，而是一個(gè)業(yè)務(wù)問(wèn)題。比如筆者曾經(jīng)參與過(guò)兩套支付系統(tǒng)的建設(shè)：現(xiàn)今回想起來(lái)一套核心域是訂單，另一套則是賬戶(hù)。因?yàn)檫@兩套系統(tǒng)在不同的商業(yè)模型中回答上面的問(wèn)題是截然不同的。

找到了核心域，那么自然就可以基于核心域找到其他的如支撐域和通用域等等。支撐域是輔助核心域的（它不通用），通用域是貫穿到整個(gè)流程中的一些共用環(huán)節(jié)。

但當(dāng)我們一旦明確了核心域，我們應(yīng)該將核心域的建設(shè)排在首位，最好是有絕對(duì)的掌控能力和自主研發(fā)能力，如果資源實(shí)在有限的話(huà)，可以在支撐域或者通用域上想想辦法，暫時(shí)采用外購(gòu)的方式也未嘗不可。所以當(dāng)我們需要外包時(shí)，我們應(yīng)該盡可能的外包非核心域的東西，盡可能的選擇其他部分。（當(dāng)然如何控制外包的質(zhì)量，后面再談）

回到我上面的這個(gè)示例：我這個(gè)支付系統(tǒng)有訂單，但由于這個(gè)系統(tǒng)后面不光只是支付收單，還涉及到理財(cái)，錢(qián)包，以及海外貨幣匯兌（海外牌照）等等業(yè)務(wù)，所以這個(gè)系統(tǒng)的核心域自然是賬戶(hù)體系。 但之前為另一個(gè)支付系統(tǒng)為什么核心域是訂單了，因?yàn)橹暗囊粋€(gè)系統(tǒng)就是簡(jiǎn)單的收集支付訂單，核對(duì)流水，最后把整個(gè)訂單金額去向進(jìn)行留存歸檔即可，所以核心域是不一樣的。