GitChatDDD課程微信群?jiǎn)柎?br>2021-07-22 18:01:21

我在GitChat發(fā)布了《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐》戰(zhàn)略篇+戰(zhàn)術(shù)篇課程，購買該課程的學(xué)員還可以免費(fèi)加入由我創(chuàng)建，GitChat維護(hù)的DDD微信群。目前，已創(chuàng)建三個(gè)微信群，人數(shù)達(dá)到1200人左右。在這三個(gè)群里，每天都有DDD的愛好者參與激烈的討論，討論的質(zhì)量也格外的高。我?guī)缀蹩梢宰院赖卣f，天下DDD英雄已盡在群中矣。

感謝志愿者@子魚每天不辭辛勞對(duì)群里問題的收集。本文遴選了部分問題給以回答。

DDD事件風(fēng)暴如何落地

背景：電商履約過程中， 確定一個(gè)訂單具體進(jìn)哪一個(gè)倉的因素多， 以往的實(shí)現(xiàn)方式是把這些規(guī)則收集起來逐個(gè)實(shí)現(xiàn)。

問題：針對(duì)訂單定倉的場(chǎng)景， 事件風(fēng)暴中， 可能只有一句話， 表示成“訂單已定倉”。背后那些復(fù)雜的規(guī)則及規(guī)則之間的綜合判斷邏輯，沒有體現(xiàn)出來， 也就不方便用DDD的思路改造。請(qǐng)幫看下， 這樣業(yè)務(wù)上可能一帶而過但具體實(shí)現(xiàn)復(fù)雜的功能點(diǎn)， 怎么借助DDD改造優(yōu)化下？

提問者之后又補(bǔ)充道：

具體實(shí)施上有些問題：

• 公司沒有領(lǐng)域?qū)＜摇?/p>

• 有業(yè)務(wù)方， 不過業(yè)務(wù)方不穩(wěn)定， 經(jīng)常換人， 反倒不如落到代碼上的經(jīng)驗(yàn)具體和全面。

我的回答：

實(shí)際上這個(gè)問題充分說明我們?cè)趯?shí)踐事件風(fēng)暴時(shí)，并沒有得到合理運(yùn)用。事件風(fēng)暴究竟優(yōu)勢(shì)在哪里？事件并非靈丹妙藥，因?yàn)橛辛怂?，業(yè)務(wù)就一下子變得清晰了。哪有這么容易的事兒。如果真正實(shí)踐過事件風(fēng)暴，你會(huì)發(fā)現(xiàn)它的核心思想其實(shí)仍然是通過識(shí)別出領(lǐng)域知識(shí)中各個(gè)細(xì)小但關(guān)鍵的概念，然后針對(duì)這些概念進(jìn)行抽象、歸納，算是一種自底向上的分析過程，只不過表現(xiàn)形式不再是功能、用例、或者類。

實(shí)踐事件風(fēng)暴與傳統(tǒng)建模方法不同之處在于：

• 它非常強(qiáng)調(diào)領(lǐng)域?qū)＜遗c全團(tuán)隊(duì)的參與。如果公司沒有領(lǐng)域?qū)＜?，也需要邀?qǐng)具有業(yè)務(wù)知識(shí)的角色參與到事件風(fēng)暴的過程中來。
• 它非常強(qiáng)調(diào)可視化的溝通形式與面對(duì)面的交流形式。利用各種顏色的即時(shí)貼表示不同的概念，并以清晰直觀地事件流呈現(xiàn)出來，就能消除交流的誤解，打破溝通可能存在的堅(jiān)冰。

至于事件產(chǎn)生的驅(qū)動(dòng)力，以及事件風(fēng)暴的過程，在我的課程中已有介紹，這里就不再贅述。

核心子領(lǐng)域還是支撐子領(lǐng)域

問題：請(qǐng)問各位大佬,公司要做促銷系統(tǒng), 在下準(zhǔn)備根據(jù)ddd的思想來做, ，但是想到要?jiǎng)澐趾诵挠? 通用域,支撐域的時(shí)候,針對(duì)于公司,整個(gè)促銷系統(tǒng)都不是核心 , 是不是這里就直接整個(gè)系統(tǒng)都當(dāng)做一個(gè)支撐域就行了?

我的回答：

這個(gè)問題也是許多初涉DDD的人容易誤解的。Eric Evans在討論核心領(lǐng)域時(shí)，當(dāng)然是針對(duì)你要開發(fā)的系統(tǒng)而言，只有對(duì)你的系統(tǒng)而言最有價(jià)值，最值得投資的領(lǐng)域才是你的核心領(lǐng)域。Vernon在《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》書中，就闡釋得更清晰一些，他認(rèn)為分辨子領(lǐng)域到底是核心，還是通用或者支撐，需要結(jié)合具體的場(chǎng)景來考慮。例如在電商系統(tǒng)中，地圖領(lǐng)域就是支撐子領(lǐng)域，但是對(duì)于做地圖系統(tǒng)的團(tuán)隊(duì)而言，地圖領(lǐng)域就是核心子領(lǐng)域了。

促銷系統(tǒng)或許不是公司的核心領(lǐng)域，但是這里要實(shí)施DDD的是促銷系統(tǒng)，毫無疑問，你應(yīng)該為促銷系統(tǒng)劃分核心子領(lǐng)域、支撐子領(lǐng)域以及通用子領(lǐng)域。除非整個(gè)領(lǐng)域的問題域非常小，自然沒有拆分的必要。

順便說以下，Eric Evans在《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》書中僅僅提出了核心領(lǐng)域（注意是核心領(lǐng)域，而非核心子領(lǐng)域）與通用子領(lǐng)域，Vernon的書中則增加了支撐子領(lǐng)域。為了概念的一致性，統(tǒng)一稱之為：核心子領(lǐng)域、支撐子領(lǐng)域與通用子領(lǐng)域。

六邊形架構(gòu)

問題：我們的定向開發(fā)思維，導(dǎo)致在對(duì)分層架構(gòu)時(shí)很好理解；但對(duì)于六邊型架構(gòu)，雖然看過很多次，但還是不能想像出具體的代碼實(shí)現(xiàn)。請(qǐng)問六邊型架構(gòu)有具體的源碼嗎？

回答：

群里已有精彩的回答。

Qiao Liang: 洋蔥架構(gòu)?https://youtu.be/o_TH-Y78tt4?bob martin講的挺清楚的

忘卻錄音：整潔架構(gòu)，微內(nèi)核架構(gòu)，架構(gòu)設(shè)計(jì)模式 都是通過分離關(guān)注點(diǎn)，劃分邊界的方式。達(dá)到結(jié)構(gòu)的清晰與一致

lucoo：阿里的cola?https://github.com/alibaba/COLA

孔令秋：六邊形架構(gòu)的核心是隔離耦合，六邊形架構(gòu)將系統(tǒng)分為兩個(gè)部分，系統(tǒng)的業(yè)務(wù)邏輯與系統(tǒng)依賴的其他部分（其他部分包括各種中間件，其他的微服務(wù)，數(shù)據(jù)庫等等），六邊形架構(gòu)最好結(jié)合maven來使用，一個(gè)微服務(wù)對(duì)應(yīng)一個(gè)project，一個(gè)project多個(gè)module，最核心的三個(gè)module分別是應(yīng)用層，領(lǐng)域?qū)?，基礎(chǔ)設(shè)施層，其中基礎(chǔ)設(shè)施層引用其他兩層，這樣就實(shí)現(xiàn)了依賴倒置，依賴倒置也就隔離了耦合，同時(shí)單元測(cè)試也會(huì)變得容易

阿斌哥： 六邊形架構(gòu)的入站適配器對(duì)應(yīng)張老師所說的北向網(wǎng)關(guān)，出站適配器對(duì)應(yīng)南向網(wǎng)關(guān)，入站端口對(duì)應(yīng)應(yīng)用服務(wù)，出站端口對(duì)應(yīng)南向網(wǎng)關(guān)的抽象。依賴倒置的核心就在那一層南向網(wǎng)關(guān)的抽象。

我的補(bǔ)充：

六邊形架構(gòu)其實(shí)相當(dāng)于是隔離內(nèi)外的分層架構(gòu)，在學(xué)習(xí)時(shí)，你可以將兩個(gè)六邊形隔離出來的三個(gè)區(qū)域映射到分層架構(gòu)上幫助你理解。我的GitChat課程其實(shí)已經(jīng)較清晰地分析了分層架構(gòu)、六邊形架構(gòu)與整潔架構(gòu)之間的關(guān)系，以及分層架構(gòu)的演進(jìn)。

在內(nèi)外兩個(gè)六邊形之間的區(qū)域都是適配器（Adapter）。如果是六邊形外部向內(nèi)部的適配器發(fā)起請(qǐng)求，則該適配器稱之為Driving Adapter，也就是我說的“北向網(wǎng)關(guān)”；反之，該適配器稱之為Driven Adapter，也就是我說的“南向網(wǎng)關(guān)”。

如果結(jié)合DDD的模式來理解，北向網(wǎng)關(guān)就是上下文映射中的“開放主機(jī)服務(wù)（OHS）”模式，服務(wù)可以分為：

• Resource：REST資源服務(wù)
• Provider：RPC提供者服務(wù)
• Controller：面向前端UI的控制器服務(wù)
• Event Subscriber：面向事件的訂閱者

這些服務(wù)傳遞的DTO（我稱之為消息契約對(duì)象）就是上下文映射中的“發(fā)布語言（Published Language）”模式。

南向網(wǎng)關(guān)就是上下文映射中的“防腐層（ACL）”模式，常見的防腐層包括：

• Client：對(duì)被調(diào)用（上游）服務(wù)接口的封裝
• Event Publisher：發(fā)布事件

實(shí)際上，我們也可以將對(duì)數(shù)據(jù)庫訪問的封裝即資源庫（Repository）視為是一種防腐層。我在GitHub上創(chuàng)建的項(xiàng)目EAS-DDD的代碼結(jié)構(gòu)其實(shí)就是按照這一思路來創(chuàng)建的，也可以認(rèn)為它遵循了六邊形架構(gòu)的設(shè)計(jì)原則。

目前，我看到講解六邊形模式（即端口適配器模式）最好的是ThoughtWorks的周宇剛撰寫的文章《端口和適配器架構(gòu)——DDD好幫手》。本文發(fā)表于ThoughtWorks洞見，講解思路非常清晰，作者對(duì)該模式的理解爐火純青，真的是從本質(zhì)上剖析了該模式與DDD的結(jié)合。推薦閱讀。