一種新型的系統(tǒng)設(shè)計(jì)解決方案：模塊樹驅(qū)動設(shè)計(jì)

作者：阿福德 2023-07-03 19:40:21

軟件行業(yè)從傳統(tǒng)的瀑布開發(fā)模式，過渡到了敏捷開發(fā)模式，對于文檔，敏捷宣言中說的是“工作的軟件高于詳盡的文檔”，但實(shí)際工作中開發(fā)人員寫的文檔是越來越少，或者是能不寫就不寫；流程上，更是恨不得需求還沒有出來就直接擼代碼，擼完代碼就直接上線。

一、前言

系統(tǒng)設(shè)計(jì)的核心作用是在業(yè)務(wù)現(xiàn)實(shí)世界和抽象的IT實(shí)現(xiàn)之間建立起一道橋梁。

與其他行業(yè)被物理特性限制所束縛不同，軟件世界可以變得無限龐大，而限制軟件發(fā)展的其實(shí)是人的認(rèn)知能力。所有軟件設(shè)計(jì)服務(wù)的目標(biāo)其實(shí)都是管理人的認(rèn)知，是關(guān)于人有限的精力如何學(xué)習(xí)軟件中無限多的知識（Knowledge）的問題。

缺乏整體系統(tǒng)設(shè)計(jì)，設(shè)計(jì)出來的系統(tǒng)就不夠完善，再加上快速的系統(tǒng)迭代，導(dǎo)致系統(tǒng)越來越難以維護(hù)，開發(fā)成本越來越高，一個(gè)項(xiàng)目需要參與的人越來越多，最終沒有人能夠說明清楚，這個(gè)系統(tǒng)具體是如何運(yùn)行的了。隨著團(tuán)隊(duì)人員的更替，加上每個(gè)人的設(shè)計(jì)思路又不一樣，更加加重了系統(tǒng)的復(fù)雜性。

上面也就引入了兩個(gè)問題：

缺乏文檔問題：不清楚系統(tǒng)長什么樣？
軟件復(fù)雜度高的問題：迭代修改系統(tǒng)的成本高。

上面兩個(gè)問題在MTDD都有相應(yīng)的解法，后面我們會詳細(xì)講述，接下來我還是再詳談一下軟件復(fù)雜度。

2、軟件復(fù)雜度

2.1 軟件復(fù)雜度的癥狀和原因

《軟件設(shè)計(jì)哲學(xué)》這本書中提到，軟件復(fù)雜度的三種癥狀：

變化放大：需要修改一個(gè)地方，卻發(fā)現(xiàn)改動的點(diǎn)涉及全站，導(dǎo)致難度倍增；
認(rèn)知負(fù)荷：開發(fā)者需要完成一項(xiàng)任務(wù)的知識量；
未知：開發(fā)者在修改代碼后，不知道它的實(shí)際影響面。

為了從源頭上解決這些問題，John Ousterhout教授提出：從項(xiàng)目一開始就要嚴(yán)格遵循進(jìn)行軟件設(shè)計(jì)的原則，那些為了趕工期而沒有經(jīng)過良好設(shè)計(jì)的代碼，最終經(jīng)過多次迭代后，都會變得越來越臃腫，繼而變得再也無法維護(hù)了。

我非常認(rèn)可John Ousterhout的觀點(diǎn)，但

實(shí)際操作中發(fā)現(xiàn)基本不具有可行性，原因：

.從瀑布模式到敏捷開發(fā)，已經(jīng)很難回去了。
是否遵循良好的軟件設(shè)計(jì)原則很難衡量。
沒有這么多的時(shí)間來檢查（代碼review，設(shè)計(jì)renview）是否有按照這些原則來設(shè)計(jì)和編碼。

我的觀點(diǎn)

對于“簡化模塊依賴”，“減少模糊性”，“高內(nèi)聚低耦合”這些原則的話術(shù)，知道的人就知道怎么做，不知道的人還是不知道怎么做。這些術(shù)語缺少實(shí)際的指導(dǎo)性。

2.2 軟件復(fù)雜度是怎么引入的（另外一個(gè)角度）

2.2.1 我們來看一個(gè)例子

圖片

2.2.2 系統(tǒng)到底是誰做出來的

一個(gè)有意思的現(xiàn)象：

圖片

那系統(tǒng)到底是誰做出來的呢？（這里主要說的是業(yè)務(wù)系統(tǒng)。一些中間件之類的系統(tǒng)，基本都都由研發(fā)來完成的。）

圖片

系統(tǒng)設(shè)計(jì)離不開，業(yè)務(wù)人員、產(chǎn)品經(jīng)理以及技術(shù)研發(fā)的合作，業(yè)務(wù)和產(chǎn)品的需求沒有理清楚，同樣會導(dǎo)致系統(tǒng)復(fù)雜度提升。

2.2.3 另外一種系統(tǒng)復(fù)雜度引入環(huán)節(jié)

圖片

系統(tǒng)各主要相關(guān)方缺乏對系統(tǒng)設(shè)計(jì)的信息拉齊，給系統(tǒng)復(fù)雜度的提升同樣有重要的貢獻(xiàn)。

那么如何讓各角色更好的進(jìn)行信息對齊，這就引入了MTDD。

3、一種新型的系統(tǒng)設(shè)計(jì)解決方案：MTDD

前面提到了《軟件設(shè)計(jì)哲學(xué)》作者提出了一些系統(tǒng)設(shè)計(jì)總結(jié)，也有些人提出了一些方法論，比如領(lǐng)域驅(qū)動設(shè)計(jì)（DDD），測試驅(qū)動開發(fā)（TDD），行為驅(qū)動開發(fā)（BDD）；但是這些模式，都是從設(shè)計(jì)方法論上給與指導(dǎo)，戰(zhàn)術(shù)上指導(dǎo)偏少。下面我們來介紹我自己沉淀的一個(gè)方法論，和戰(zhàn)術(shù)指導(dǎo)MTDD&MTDP。

3.1 MTDD是什么

MTDD的全稱是：Module Tree Drive Design, 模塊樹驅(qū)動設(shè)計(jì)，也可以叫做能力樹驅(qū)動設(shè)計(jì)。MTDD是一種系統(tǒng)設(shè)計(jì)模式，并同時(shí)提供了戰(zhàn)術(shù)層的SDK。

MTDD主要思想是讓業(yè)務(wù)，產(chǎn)品、研發(fā)共同對復(fù)雜業(yè)務(wù)系統(tǒng)中的模塊進(jìn)行分析，并對這些業(yè)務(wù)模塊做好分層分類，最終形成各方達(dá)成一致的一棵模塊樹；研發(fā)人員開發(fā)可以通過給定的SDK，將系統(tǒng)中的代碼按照模塊的方式進(jìn)行打標(biāo)分類，系統(tǒng)根據(jù)代碼中打標(biāo)分類，自動生成一顆可視化的模塊樹。通過這個(gè)方式，讓系統(tǒng)與業(yè)務(wù)保持高度一致。

MTDD從某個(gè)方面說也是DDD領(lǐng)域驅(qū)動設(shè)計(jì)中所宣導(dǎo)的統(tǒng)一語言一種實(shí)現(xiàn)方式。

MTDD思想主要體現(xiàn)在：

當(dāng)業(yè)務(wù)和產(chǎn)品需要對系統(tǒng)能力進(jìn)行新增、修改、或者擴(kuò)展時(shí)，可以對照系統(tǒng)這顆可視化的模塊樹進(jìn)行溝通，然后進(jìn)行思考和設(shè)計(jì)具體的哪個(gè)或者哪些模塊需要進(jìn)行修改或者擴(kuò)展，并產(chǎn)出修改后的最終結(jié)果。
研發(fā)人員接到接到需求后開發(fā)完成后，新開發(fā)的功能就會自動的在系統(tǒng)的模塊樹上進(jìn)行呈現(xiàn)。
產(chǎn)品和業(yè)務(wù)驗(yàn)收時(shí)，就可以對照系統(tǒng)上的模塊樹，進(jìn)行功能驗(yàn)收。

3.2 MTDD的特點(diǎn)

3.2.1 模塊化

在系統(tǒng)設(shè)計(jì)中，模塊是指一組相互依賴的程序元素，通常是在模塊內(nèi)部完成特定的工作。模塊也可以被組合以形成更大的、更復(fù)雜的系統(tǒng)。子模塊則是模塊的一部分，通常是實(shí)現(xiàn)特定的功能。

在MTDD中，模塊化更多的是從業(yè)務(wù)的角度上來說的，比如一個(gè)營銷觸達(dá)模塊，比如倉儲系統(tǒng)中的入庫模塊；模塊下面還可以有子模塊，子模塊也可以有子子模塊，這個(gè)可以根據(jù)一定的顆粒度進(jìn)行靈活拆分，重點(diǎn)是業(yè)務(wù)，產(chǎn)品、研發(fā)三方達(dá)成一致，并且明確模塊的關(guān)系（父子關(guān)系）。

3.2.2 分類與分層

將模塊化的模板進(jìn)行分層分類。

在系統(tǒng)設(shè)計(jì)中，分層和分類是非常重要的，這有助于提高系統(tǒng)的可擴(kuò)展性和可維護(hù)性，也能很好的降低人的認(rèn)知負(fù)荷。

OOD（面對對象設(shè)計(jì)）本質(zhì)就是一種分類思想。
DDD（領(lǐng)域驅(qū)動設(shè)計(jì)）本質(zhì)也是一種分類思想。

分層設(shè)計(jì)：

在現(xiàn)實(shí)世界中，所有我們見到的事物，人類都自然的對其給與了分層，比如：

圖片

再比如在倉儲管理中，也會有天然的分層：

圖片

分層分類-復(fù)雜度分解：

我們的目標(biāo)是將一些同類型的提高一個(gè)抽象層次，將大腦比較難處理的9個(gè)概念簡化成3個(gè)，這樣就無需記憶其中的每個(gè)概念，另外由于較高層次的思想總是能夠提示下面一個(gè)層次的思想，所以記憶起來會更方便。所有的思維過程（思考、記憶、解決問題）都應(yīng)該使用這樣的分組和概括的方法，將大腦中的無序信息組成一個(gè)相關(guān)關(guān)聯(lián)的金字塔結(jié)構(gòu)。

每個(gè)模塊下又可以有多個(gè)子模塊。

總而言之，設(shè)計(jì)人員對模塊進(jìn)行分層分類后，可以大大降低思考復(fù)雜度，這個(gè)很好理解。

圖片

3.2.3 可視化

分層分類的模塊以樹狀接口進(jìn)行可視化呈現(xiàn)。

左邊圖描述的是：業(yè)務(wù)、產(chǎn)品、研發(fā)對齊需求后，認(rèn)為的業(yè)務(wù)系統(tǒng)上需要建設(shè)兩個(gè)子模塊的能力。

右邊的圖是：研發(fā)實(shí)現(xiàn)產(chǎn)品需求后，系統(tǒng)自動生成的能力樹的樣子。

3.2.4 強(qiáng)大的配置化能力

所有的業(yè)務(wù)配置，都是業(yè)務(wù)相關(guān)的，系統(tǒng)用來控制業(yè)務(wù)的邏輯，本質(zhì)就是業(yè)務(wù)的一部分。在傳統(tǒng)的業(yè)務(wù)系統(tǒng)中一般有兩種方式來實(shí)現(xiàn)：

使用需要一個(gè)配置中心，配置中心一般都使用key-value的方式來存儲。業(yè)務(wù)系統(tǒng)根據(jù)配置的key到配置中心來獲取value，并解析value的值。業(yè)務(wù)人員直接在配置中心來做配置值的修改。
每個(gè)配置單獨(dú)開發(fā)配置頁面，業(yè)務(wù)人員在配置頁面上進(jìn)行值修改。

這兩種方式都存在一些問題：

使用配置中心，雖然將所有的配置都進(jìn)行了統(tǒng)一，但是面對一些負(fù)責(zé)配置時(shí)，需要采用類似json這種格式來存儲，修改的時(shí)候只能修改json的值，無法通過頁面富樣式頁面來修改。
每個(gè)頁面單獨(dú)開發(fā)配置頁面，對配置友好，但是開發(fā)工作量大，因?yàn)槊總€(gè)配置都需要前端開發(fā)。

使用MTDD配置化能力時(shí)，就可以解決上面兩個(gè)問題

業(yè)務(wù)配置一定屬于具體的業(yè)務(wù)模塊，因?yàn)榕渲檬怯脩艨刂颇硞€(gè)具體的模塊邏輯，所以配置盡量掛在模塊下面是一個(gè)非常自然的做法。

我的觀點(diǎn)

3.2.5 其他優(yōu)勢

讓業(yè)務(wù)，產(chǎn)品，在提需求的時(shí)候，就能夠以系統(tǒng)能力的方式去思考。
在有新需求時(shí)，產(chǎn)研可以方便的在能力樹上找到需要改動的模塊。
測試的影響范圍也很容易確定。對修改友好，影響范圍可控。
讓程序員天然的進(jìn)行開閉原則，對新增開放，對修改改封閉。

3.3 MTDD作用與總結(jié)

系統(tǒng)設(shè)計(jì)的核心作用是在業(yè)務(wù)現(xiàn)實(shí)世界和抽象的IT實(shí)現(xiàn)之間建立起一道橋梁。而業(yè)務(wù)系統(tǒng)本身就是現(xiàn)實(shí)世界在計(jì)算機(jī)系統(tǒng)中的映射。

現(xiàn)實(shí)世界是一個(gè)模塊化的，層次化的樹狀結(jié)構(gòu)，所以業(yè)務(wù)系統(tǒng)就應(yīng)該自然的通過模塊化的樹狀結(jié)構(gòu)來進(jìn)行映射。

MTDD正是基于此，通過一個(gè)可視化的能力樹，這顆能力樹作為實(shí)實(shí)在在，可以看得見的橋梁，來拉齊業(yè)務(wù)、產(chǎn)品和系統(tǒng)研發(fā)。并最終做到讓業(yè)務(wù)和產(chǎn)品，可以真正以產(chǎn)品能力搭建的視角來規(guī)劃，設(shè)計(jì)系統(tǒng)模塊和系統(tǒng)功能。可以讓系統(tǒng)架構(gòu)人員自然而然的進(jìn)行高內(nèi)聚，低耦合的系統(tǒng)設(shè)計(jì)，可以讓一線研發(fā)自然而然的進(jìn)行模塊化編程。

模塊樹驅(qū)動設(shè)計(jì)閉環(huán)

圖片

4、MTDD實(shí)戰(zhàn)

4.1 MTDD戰(zhàn)略層

4.1.1 統(tǒng)一語言

DDD中也有統(tǒng)一語言，或者叫做“通用語言（Ubiquitous Language ）”

當(dāng)團(tuán)隊(duì)成員不能享用一個(gè)公共語言來討論領(lǐng)域時(shí)，項(xiàng)目會面臨嚴(yán)重的問題。領(lǐng)域?qū)＜沂褂米约旱男性挘夹g(shù)團(tuán)隊(duì)成員在設(shè)計(jì)中也用自己的語言討論領(lǐng)域。

代碼可能是一個(gè)軟件項(xiàng)目中最重要的產(chǎn)物，但每天用來討論的術(shù)語卻與代碼中使用的術(shù)語脫節(jié)了。即使是同一個(gè)人都需要使用不同的語言來交談和書寫，所以要想完成對領(lǐng)域的深刻表達(dá)通常需要產(chǎn)生一種臨時(shí)形式，但這種形式不會出現(xiàn)在代碼甚至是書寫的內(nèi)容中。

在交流的過程中，需要做翻譯才能讓其他的人理解這些概念。開發(fā) 人員可能會努力使用外行人的語言來解析一些設(shè)計(jì)模式，但這并一定都能成功奏效。領(lǐng)域?qū)＜乙部赡軙?chuàng)建一種新的行話以努力表達(dá) 他們的這些想法。在這個(gè)痛苦的交流過程中，這種類型的翻譯并不能對知識的構(gòu)建過程產(chǎn)生幫助。

上面這段是話是摘自《領(lǐng)域驅(qū)動設(shè)計(jì)精簡版》

Eric Evans 早就意識到，需要在領(lǐng)域?qū)＜液脱邪l(fā)之間共用一套通用語言，并且Eric Evans也做了大量的舉例說明，來說明什么是通用語言，以及統(tǒng)一通用語言可以更好的服務(wù)于系統(tǒng)設(shè)計(jì)。

MTDD更也是站在巨人的肩膀上，提供了一個(gè)方法論：讓業(yè)務(wù)，產(chǎn)品，技術(shù)在系統(tǒng)設(shè)計(jì)之前，一起對照系統(tǒng)模塊樹來進(jìn)行溝通；對于一個(gè)新功能，一起思考是在某個(gè)模塊下新增模塊，還是修改貨擴(kuò)展模塊內(nèi)部的邏輯；在對齊后，就可以進(jìn)行開發(fā)了，并且研發(fā)有一定的范式開做開發(fā)，開發(fā)后，系統(tǒng)的模塊樹就能夠自動可視化的呈現(xiàn)出來；業(yè)務(wù)和產(chǎn)品也可以通過可視化的方式進(jìn)行驗(yàn)收；

4.1.2 按定制規(guī)范來做設(shè)計(jì)和開發(fā)

上面說了在業(yè)務(wù)方、產(chǎn)品、技術(shù)在參照能力樹根據(jù)需求并對齊需要開發(fā)的模塊后，研發(fā)可以按照一定的范式做系統(tǒng)開發(fā)；這是因?yàn)槲覀兲峁┝艘惶组_發(fā)的SDK，以及SDK的使用文檔，來幫助研發(fā)人員來進(jìn)行基于能力樹功能的開發(fā)。系統(tǒng)功能開發(fā)完成后，相應(yīng)的模塊信息就可以自動在模塊樹頁面上進(jìn)行呈現(xiàn)。當(dāng)然想要在頁面上進(jìn)行呈現(xiàn)，需要有前端來支持。

這個(gè)規(guī)范主要由幾個(gè)主要的java注解來實(shí)現(xiàn)：

@Module
@ModuleConfig
@ConfigItem

4.1.3 系統(tǒng)的模塊化以及分層分類

使用上面的java注解，對代碼中模塊進(jìn)行打標(biāo)。

業(yè)務(wù)模塊化，并且做了分層與分類，那么系統(tǒng)中的代碼需要根據(jù)業(yè)務(wù)中的分層分類進(jìn)行進(jìn)行分類打標(biāo)，使其與業(yè)務(wù)分層分類保持一致。

4.1.4 持續(xù)重構(gòu)（Continue Refactor）

我們這個(gè)世界夠復(fù)雜了吧，如果讓你設(shè)計(jì)一個(gè)IT系統(tǒng)來實(shí)現(xiàn)刻畫這個(gè)世界的方方面面，我打賭一定沒有人搞得定；但現(xiàn)實(shí)中的這個(gè)世界還是能夠有條不紊的發(fā)展演進(jìn)，沒有需要出現(xiàn)“推倒重來”的現(xiàn)象，為什么呢，我認(rèn)為是我們的世界一直在用各種方式不停的重構(gòu)。

“物競天擇，適者生存”出自達(dá)爾文的進(jìn)化論，達(dá)爾文在1859年出版的《物種起源》一書中系統(tǒng)地闡述了他的進(jìn)化學(xué)說。物競天擇，適者生存是指物種之間及生物內(nèi)部之間相互競爭，物種與自然之間的抗?fàn)帲苓m應(yīng)自然者被選擇存留下來的一種叢林法則。

對于軟件系統(tǒng)也是這樣，業(yè)務(wù)是在不停的發(fā)展，我們的認(rèn)知也是一直不斷的更新，當(dāng)“我們”通過可視化的能力樹發(fā)現(xiàn)一些突兀時(shí)，那肯定是某個(gè)或者某些模塊拆分不正確，或者模塊提供的能力不合適，這時(shí)，我們就可以考慮對模塊樹進(jìn)行重構(gòu)了，要么是拆分模塊，要么是調(diào)整模塊的關(guān)系，要么是修改模塊的職責(zé)。

4.1.5 關(guān)于產(chǎn)品需求

如果產(chǎn)品了解MTDD，那么就會提出更加符合產(chǎn)品化的需求了

如果研發(fā)對MTDD理解深入，那么當(dāng)產(chǎn)品的需求不符合產(chǎn)品化，能力化時(shí)，就會與產(chǎn)品進(jìn)行溝通，產(chǎn)品修改需求，以便更好的設(shè)計(jì)出產(chǎn)品化，系統(tǒng)能力化的需求。

?好的產(chǎn)品需求	×不好的產(chǎn)品需求
對現(xiàn)有系統(tǒng)能力的擴(kuò)展增加新的系統(tǒng)能力	針對特定的業(yè)務(wù)需求定制系統(tǒng)能力

4.2 MTDD戰(zhàn)術(shù)層（MTDP）

MTDP的全稱是Module Tree Drive Programing, 領(lǐng)域樹驅(qū)動編程。

4.2.1 模塊

注解@Module的定義

/**
 *
 * 模塊注解，打在一個(gè)服務(wù)類上，Module注解是繼承了Component注解，因此它注解的類可以被實(shí)例化到Spring中去
 * 服務(wù)啟動時(shí)會掃碼所有Module類，將他們組裝成樹進(jìn)行持久化。
 */
@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
@Documented
public @interface Module {
    /**
     * 該模塊的key
     * 在設(shè)置模塊的key的時(shí)候，在同一個(gè)服務(wù)里面（同一個(gè)根節(jié)點(diǎn)），如果兩個(gè)類設(shè)置的key是一樣，最后會被去重為一個(gè)模塊，無論是單體服務(wù)還是分布式工程。
     * moduleKey全局唯一，就算它們歸屬不同的根節(jié)點(diǎn)，也不能設(shè)置一樣的moduleKey，
     * 不同根節(jié)點(diǎn)的模塊，如果設(shè)置了同一個(gè)moduleKey，后部署的服務(wù)將無法能力樹的變更情況進(jìn)行持久化。
     * @return
     */
    String moduleKey();
    /**
     * 用于指定該模塊的父模塊，
     * 根節(jié)點(diǎn)的parentModule指定為 {@link Void}.class。
     * 每個(gè)模塊指定他們的夫模塊，直到可達(dá)根節(jié)點(diǎn)，最后生成一顆樹。
     * 指定parentModule時(shí)一定要注意，不能循環(huán)依賴了，循環(huán)依賴的情況下，服務(wù)將拋出異常無法啟動，
     * @return
     */
    Class<?> parentModule();


    /**
     * 該模塊名稱
     * @return
     */
    String moduleName();


    /**
     * 模塊描述，一個(gè)該模塊詳細(xì)的描述
     * @return
     */
    String moduleRemark() default "";
    /**
     * 能否被剪枝，你是可以設(shè)置模塊能不能被剪枝，默認(rèn)是不可以的（后續(xù)會根據(jù)數(shù)量對比情況進(jìn)行調(diào)整默認(rèn)值）。
     * 我們應(yīng)該將系統(tǒng)中必要的功能設(shè)置為無法裁減，將那些加強(qiáng)性的能力，智能化的能力，衍生化的能力，非基本的能力設(shè)置為可以裁減
     * @return
     */
    boolean cutAble() default false;
}

模塊的具體例子：

@Module(moduleKey = "scm.wms", moduleName = "WMS", parentModule = NULL)
public class WmsModule {
    //業(yè)務(wù)邏輯
}


@Module(moduleKey = "scm.wms.inner.test1", moduleName = "測試模塊1", parentModule = WmsModule.class)
public class InnerTestModule1 {
    //業(yè)務(wù)邏輯
}


@Module(moduleKey = "scm.wms.inner.test2", moduleName = "測試模塊2", parentModule = WmsModule.class)
public class InnerTestModule2 {
    //業(yè)務(wù)邏輯
}

4.2.2 模塊樹

每個(gè)模塊都有父模塊ParentModule，跟模塊的父模塊為NULL，模塊樹則是由所有模塊組成的一個(gè)樹狀結(jié)構(gòu)的樹。

圖片

4.2.3 裁剪與恢復(fù)

圖片

4.2.4 模塊配置

找到模塊上的配置，點(diǎn)擊展開配置

圖片

展開配置如下：

圖片

上面的配置，是無需前端進(jìn)行開發(fā)，只需要后端實(shí)現(xiàn)就好，后端代碼：

@Data
@ModuleConfig(configKey = "scm.wms.inbound.receive.oneBarcodeMuliSku", configName = "收貨一碼多品配置", module="scm.wms.inbound.receive")
public class ReceiveScanOneCodeMoreSkuModuleConfig {
    @ConfigItem(itemName = "是否開啟一碼多品的攔截"
            , itemRemark = "如果關(guān)閉, 一碼多品的商品在收貨時(shí), 不會收到\"該條碼對應(yīng)多個(gè)商品，請打印商品標(biāo)簽\"的提醒, prd:https://poizon.feishu.cn/wiki/wikcnstRj3Qfbn4fXDrmvBk6R0d"
            , defaultValue = "true")
    private Boolean isOpen;
    @ConfigItem(itemName = "攔截方式"
            , itemRemark = "如果配置強(qiáng)攔截，則必須打印商品標(biāo)簽, 阻斷收貨流程。如果配置弱攔截, 只是提醒一下, 不阻斷收貨流程"
            , scopeClass = InterceptType.class
            , defaultValue = "WEAK")
    private String interceptType;
    @ConfigItem(itemName = "攔截規(guī)則"
            , scopeClass = InterceptRuleType.class
            , defaultValue = "ARBITRARY")
    private String interceptRule;
}

配置的幾個(gè)java注解：

ModuleConfig

/**
 * 業(yè)務(wù)配置注解，業(yè)務(wù)配置是Module的字段
 */
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ModuleConfig {
    /**
     * 配置的key
     */
    String configKey();
    /**
     * 配置名稱
     * @return
     */
    String configName();
    /**
     * 配置描述，鼠標(biāo)懸浮時(shí)的氣泡提示
     * @return
     */
    String configRemark() default "";
    /**
     * 是否必要，必要的不可以被剪枝
     * @return
     */
    boolean cutAble() default false;
}

ConfigItem 配置屬性

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ConfigItem {
    /**
     * 配置名稱
     * @return
     */
    String itemName();
    /**
     * 配置描述，鼠標(biāo)懸浮時(shí)的氣泡提示
     * @return
     */
    String itemRemark() default "";
    /**
     * 默認(rèn)值
     * @return
     */
    String defaultValue() default "";
    /**
     * 如果你的取值范圍是枚舉指定枚舉的全路徑類名,
     * 如果你的取值范圍是一種策略，指定策略的interfaces的全路徑名稱
     * @return
     */
    Class<?> scopeClass() default Void.class;
    /**
     * 范圍，默認(rèn)通用，當(dāng)你需要定制時(shí)才需要指定
     * @return
     */
    ScopeType scopeType() default ScopeType.COMMON;


    /**
     * 自定義組件，需要前端參與開發(fā)，非特殊組件，無需設(shè)置，DSK會自動給你尋找組件
     * @return
     */
    String customScopeType() default "";


    /**
     * 對位文本類型的配置，min則為文本長度限制的最小值
     * 對于數(shù)字類型的配置，min則為數(shù)字的最小值。
     */
    int min() default Integer.MIN_VALUE;


    /**
     * 對位文本類型的配置，min則為文本長度限制的最大值
     * 對于數(shù)字類型的配置，min則為數(shù)字的最大值。
     */
    int max() default Integer.MAX_VALUE;
}

5、MTDD與TMF的差別

5.1 什么是TMF

TMF 是 Trade Modularization Framework 的全稱，即交易模塊化框架，最初是交易系統(tǒng)中的一個(gè)代碼模塊，后來剔除業(yè)務(wù)耦合部分，獨(dú)立出來成為一個(gè)實(shí)現(xiàn)業(yè)務(wù)與平臺分離的業(yè)務(wù)框架。

5.2 TMF架構(gòu)

圖片

（圖片來源：https://www.cnblogs.com/shoshana-kong/p/14957739.html）

5.3 TMF2在架構(gòu)設(shè)計(jì)上主要的思想

業(yè)務(wù)包與平臺分離的插件化架構(gòu)：平臺提供插件包注冊機(jī)制，實(shí)現(xiàn)業(yè)務(wù)方插件包在運(yùn)行期的注冊。業(yè)務(wù)代碼只允許存在于插件包中，與平臺代碼嚴(yán)格分離。業(yè)務(wù)包的代碼配置庫也與平臺的代碼庫分離，通過二方包的方式，提供給容器加載。
全鏈路統(tǒng)一的業(yè)務(wù)身份：平臺需要能有按“業(yè)務(wù)身份”進(jìn)行業(yè)務(wù)與業(yè)務(wù)之間邏輯隔離的能力，而不是傳統(tǒng)SPI架構(gòu)不區(qū)分業(yè)務(wù)身份，簡單過濾的方式。如何設(shè)計(jì)這個(gè)業(yè)務(wù)身份，也成為業(yè)務(wù)間隔離架構(gòu)的關(guān)鍵。
管理域與運(yùn)行域分離：業(yè)務(wù)邏輯不能依靠運(yùn)行期動態(tài)計(jì)算，要能在靜態(tài)期進(jìn)行定義并可視化呈現(xiàn)。業(yè)務(wù)定義中出現(xiàn)的規(guī)則疊加沖突，也在靜態(tài)器進(jìn)行沖突決策。在運(yùn)行期，嚴(yán)格按照靜態(tài)器定義的業(yè)務(wù)規(guī)則、沖突決策策略執(zhí)行。

圖片