GitChatDDD課程微信群問答
2021-07-22 18:01:21

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

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

DDD事件風暴如何落地

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

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

提問者之后又補充道：

具體實施上有些問題：

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

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

我的回答：

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

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

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

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

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

問題：請問各位大佬,公司要做促銷系統(tǒng), 在下準備根據(jù)ddd的思想來做, ，但是想到要劃分核心域, 通用域,支撐域的時候,針對于公司,整個促銷系統(tǒng)都不是核心 , 是不是這里就直接整個系統(tǒng)都當做一個支撐域就行了?

我的回答：

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

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

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

六邊形架構(gòu)

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

回答：

群里已有精彩的回答。

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

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

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

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

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

我的補充：

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

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

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

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

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

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

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

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

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