系統(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í)軟件中無限多的知識(shí)（Knowledge）的問題。
(資料圖片僅供參考)
軟件行業(yè)從傳統(tǒng)的瀑布開發(fā)模式，過渡到了敏捷開發(fā)模式，對(duì)于文檔，敏捷宣言中說的是“工作的軟件高于詳盡的文檔”，但實(shí)際工作中開發(fā)人員寫的文檔是越來越少，或者是能不寫就不寫；流程上，更是恨不得需求還沒有出來就直接擼代碼，擼完代碼就直接上線。
缺乏整體系統(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)的解法，后面我們會(huì)詳細(xì)講述，接下來我還是再詳談一下軟件復(fù)雜度。
2、軟件復(fù)雜度2.1 軟件復(fù)雜度的癥狀和原因《軟件設(shè)計(jì)哲學(xué)》這本書中提到，軟件復(fù)雜度的三種癥狀：
變化放大：需要修改一個(gè)地方，卻發(fā)現(xiàn)改動(dòng)的點(diǎn)涉及全站，導(dǎo)致難度倍增；認(rèn)知負(fù)荷：開發(fā)者需要完成一項(xiàng)任務(wù)的知識(shí)量；未知：開發(fā)者在修改代碼后，不知道它的實(shí)際影響面。為了從源頭上解決這些問題，John Ousterhout教授提出：從項(xiàng)目一開始就要嚴(yán)格遵循進(jìn)行軟件設(shè)計(jì)的原則，那些為了趕工期而沒有經(jīng)過良好設(shè)計(jì)的代碼，最終經(jīng)過多次迭代后，都會(huì)變得越來越臃腫，繼而變得再也無法維護(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)
對(duì)于“簡化模塊依賴”，“減少模糊性”，“高內(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)品的需求沒有理清楚，同樣會(huì)導(dǎo)致系統(tǒng)復(fù)雜度提升。
2.2.3 另外一種系統(tǒng)復(fù)雜度引入環(huán)節(jié)圖片
系統(tǒng)各主要相關(guān)方缺乏對(duì)系統(tǒng)設(shè)計(jì)的信息拉齊，給系統(tǒng)復(fù)雜度的提升同樣有重要的貢獻(xiàn)。
那么如何讓各角色更好的進(jìn)行信息對(duì)齊，這就引入了MTDD。
3、一種新型的系統(tǒng)設(shè)計(jì)解決方案：MTDD前面提到了《軟件設(shè)計(jì)哲學(xué)》作者提出了一些系統(tǒng)設(shè)計(jì)總結(jié)，也有些人提出了一些方法論，比如領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD），測試驅(qū)動(dòng)開發(fā)（TDD），行為驅(qū)動(dòng)開發(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ū)動(dòng)設(shè)計(jì)，也可以叫做能力樹驅(qū)動(dòng)設(shè)計(jì)。MTDD是一種系統(tǒng)設(shè)計(jì)模式，并同時(shí)提供了戰(zhàn)術(shù)層的SDK。
MTDD主要思想是讓業(yè)務(wù)，產(chǎn)品、研發(fā)共同對(duì)復(fù)雜業(yè)務(wù)系統(tǒng)中的模塊進(jìn)行分析，并對(duì)這些業(yè)務(wù)模塊做好分層分類，最終形成各方達(dá)成一致的一棵模塊樹；研發(fā)人員開發(fā)可以通過給定的SDK，將系統(tǒng)中的代碼按照模塊的方式進(jìn)行打標(biāo)分類，系統(tǒng)根據(jù)代碼中打標(biāo)分類，自動(dòng)生成一顆可視化的模塊樹。通過這個(gè)方式，讓系統(tǒng)與業(yè)務(wù)保持高度一致。
MTDD從某個(gè)方面說也是DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中所宣導(dǎo)的統(tǒng)一語言一種實(shí)現(xiàn)方式。 |
MTDD思想主要體現(xiàn)在：
當(dāng)業(yè)務(wù)和產(chǎn)品需要對(duì)系統(tǒng)能力進(jìn)行新增、修改、或者擴(kuò)展時(shí)，可以對(duì)照系統(tǒng)這顆可視化的模塊樹進(jìn)行溝通，然后進(jìn)行思考和設(shè)計(jì)具體的哪個(gè)或者哪些模塊需要進(jìn)行修改或者擴(kuò)展，并產(chǎn)出修改后的最終結(jié)果。研發(fā)人員接到接到需求后開發(fā)完成后，新開發(fā)的功能就會(huì)自動(dòng)的在系統(tǒng)的模塊樹上進(jìn)行呈現(xiàn)。產(chǎn)品和業(yè)務(wù)驗(yàn)收時(shí)，就可以對(duì)照系統(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á)模塊，比如倉儲(chǔ)系統(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（面對(duì)對(duì)象設(shè)計(jì)）本質(zhì)就是一種分類思想。DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）本質(zhì)也是一種分類思想。分層設(shè)計(jì)：
在現(xiàn)實(shí)世界中，所有我們見到的事物，人類都自然的對(duì)其給與了分層，比如：
圖片
再比如在倉儲(chǔ)管理中，也會(huì)有天然的分層：
圖片
分層分類-復(fù)雜度分解：
我們的目標(biāo)是將一些同類型的提高一個(gè)抽象層次，將大腦比較難處理的9個(gè)概念簡化成3個(gè)，這樣就無需記憶其中的每個(gè)概念，另外由于較高層次的思想總是能夠提示下面一個(gè)層次的思想，所以記憶起來會(huì)更方便。所有的思維過程（思考、記憶、解決問題）都應(yīng)該使用這樣的分組和概括的方法，將大腦中的無序信息組成一個(gè)相關(guān)關(guān)聯(lián)的金字塔結(jié)構(gòu)。
每個(gè)模塊下又可以有多個(gè)子模塊。
總而言之，設(shè)計(jì)人員對(duì)模塊進(jìn)行分層分類后，可以大大降低思考復(fù)雜度， 這個(gè)很好理解。
圖片
3.2.3可視化分層分類的模塊以樹狀接口進(jìn)行可視化呈現(xiàn)。
右邊的圖是：研發(fā)實(shí)現(xiàn)產(chǎn)品需求后，系統(tǒng)自動(dò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的方式來存儲(chǔ)。業(yè)務(wù)系統(tǒng)根據(jù)配置的key到配置中心來獲取value，并解析value的值。業(yè)務(wù)人員直接在配置中心來做配置值的修改。每個(gè)配置單獨(dú)開發(fā)配置頁面，業(yè)務(wù)人員在配置頁面上進(jìn)行值修改。這兩種方式都存在一些問題：
使用配置中心，雖然將所有的配置都進(jìn)行了統(tǒng)一，但是面對(duì)一些負(fù)責(zé)配置時(shí)，需要采用類似json這種格式來存儲(chǔ)，修改的時(shí)候只能修改json的值，無法通過頁面富樣式頁面來修改。每個(gè)頁面單獨(dú)開發(fā)配置頁面，對(duì)配置友好，但是開發(fā)工作量大，因?yàn)槊總€(gè)配置都需要前端開發(fā)。使用MTDD配置化能力時(shí)，就可以解決上面兩個(gè)問題
業(yè)務(wù)配置一定屬于具體的業(yè)務(wù)模塊，因?yàn)榕渲檬怯脩艨刂颇硞€(gè)具體的模塊邏輯，所以配置盡量掛在模塊下面是一個(gè)非常自然的做法。
我的觀點(diǎn)
業(yè)務(wù)配置一定屬于具體的業(yè)務(wù)模塊，因?yàn)榕渲檬怯脩艨刂颇硞€(gè)具體的模塊邏輯，所以配置盡量掛在模塊下面是一個(gè)非常自然的做法。
3.2.5 其他優(yōu)勢讓業(yè)務(wù)，產(chǎn)品，在提需求的時(shí)候，就能夠以系統(tǒng)能力的方式去思考。在有新需求時(shí)，產(chǎn)研可以方便的在能力樹上找到需要改動(dòng)的模塊。測試的影響范圍也很容易確定。對(duì)修改友好，影響范圍可控。讓程序員天然的進(jìn)行開閉原則，對(duì)新增開放，對(duì)修改改封閉。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ū)動(dòng)設(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)目會(huì)面臨嚴(yán)重的問題。領(lǐng)域?qū)＜沂褂米约旱男性?，技術(shù)團(tuán)隊(duì)成員在設(shè)計(jì)中也用自己的語言討論領(lǐng)域。
代碼可能是一個(gè)軟件項(xiàng)目中最重要的產(chǎn)物，但每天用來討論的術(shù)語卻與代碼中使用的術(shù)語脫節(jié)了。即使是同一個(gè)人都需要使用不同的 語言來交談和書寫，所以要想完成對(duì)領(lǐng)域的深刻表達(dá)通常需要產(chǎn)生 一種臨時(shí)形式，但這種形式不會(huì)出現(xiàn)在代碼甚至是書寫的內(nèi)容中。
在交流的過程中，需要做翻譯才能讓其他的人理解這些概念。開發(fā) 人員可能會(huì)努力使用外行人的語言來解析一些設(shè)計(jì)模式，但這并一定都能成功奏效。領(lǐng)域?qū)＜乙部赡軙?huì)創(chuàng)建一種新的行話以努力表達(dá) 他們的這些想法。在這個(gè)痛苦的交流過程中，這種類型的翻譯并不能對(duì)知識(shí)的構(gòu)建過程產(chǎn)生幫助。
上面這段是話是摘自《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)精簡版 》
Eric Evans 早就意識(shí)到，需要在領(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ì)之前，一起對(duì)照系統(tǒng)模塊樹來進(jìn)行溝通；對(duì)于一個(gè)新功能，一起思考是在某個(gè)模塊下新增模塊，還是修改貨擴(kuò)展模塊內(nèi)部的邏輯；在對(duì)齊后，就可以進(jìn)行開發(fā)了，并且研發(fā)有一定的范式開做開發(fā)，開發(fā)后，系統(tǒng)的模塊樹就能夠自動(dòng)可視化的呈現(xiàn)出來；業(yè)務(wù)和產(chǎn)品也可以通過可視化的方式進(jìn)行驗(yàn)收；
4.1.2 按定制規(guī)范來做設(shè)計(jì)和開發(fā)上面說了在業(yè)務(wù)方、產(chǎn)品、技術(shù)在參照能力樹根據(jù)需求并對(duì)齊需要開發(fā)的模塊后，研發(fā)可以按照一定的范式做系統(tǒng)開發(fā)；這是因?yàn)槲覀兲峁┝艘惶组_發(fā)的SDK，以及SDK的使用文檔，來幫助研發(fā)人員來進(jìn)行基于能力樹功能的開發(fā)。系統(tǒng)功能開發(fā)完成后，相應(yīng)的模塊信息就可以自動(dòng)在模塊樹頁面上進(jìn)行呈現(xiàn)。當(dāng)然想要在頁面上進(jìn)行呈現(xiàn)，需要有前端來支持。
這個(gè)規(guī)范主要由幾個(gè)主要的java注解來實(shí)現(xiàn)：
@Module@ModuleConfig@ConfigItem4.1.3系統(tǒng)的模塊化以及分層分類
使用上面的java注解，對(duì)代碼中模塊進(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)?，能適應(yīng)自然者被選擇存留下來的一種叢林法則。
對(duì)于軟件系統(tǒng)也是這樣，業(yè)務(wù)是在不停的發(fā)展， 我們的認(rèn)知也是一直不斷的更新，當(dāng)“我們”通過可視化的能力樹發(fā)現(xiàn)一些突兀時(shí)，那肯定是某個(gè)或者某些模塊拆分不正確，或者模塊提供的能力不合適，這時(shí)，我們就可以考慮對(duì)模塊樹進(jìn)行重構(gòu)了，要么是拆分模塊，要么是調(diào)整模塊的關(guān)系，要么是修改模塊的職責(zé)。
4.1.5關(guān)于產(chǎn)品需求如果產(chǎn)品了解MTDD，那么就會(huì)提出更加符合產(chǎn)品化的需求了
如果研發(fā)對(duì)MTDD理解深入，那么當(dāng)產(chǎn)品的需求不符合產(chǎn)品化，能力化時(shí)，就會(huì)與產(chǎn)品進(jìn)行溝通，產(chǎn)品修改需求，以便更好的設(shè)計(jì)出產(chǎn)品化，系統(tǒng)能力化的需求。
?好的產(chǎn)品需求 | ×不好的產(chǎn)品需求 |
| 對(duì)現(xiàn)有系統(tǒng)能力的擴(kuò)展增加新的系統(tǒng)能力 | 針對(duì)特定的業(yè)務(wù)需求 定制系統(tǒng)能力 |
MTDP的全稱是Module Tree Drive Programing, 領(lǐng)域樹驅(qū)動(dòng)編程。
4.2.1模塊注解@Module的定義
/** * * 模塊注解，打在一個(gè)服務(wù)類上，Module注解是繼承了Component注解，因此它注解的類可以被實(shí)例化到Spring中去 * 服務(wù)啟動(dòng)時(shí)會(huì)掃碼所有Module類，將他們組裝成樹進(jìn)行持久化。 */@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE})@Retention(RetentionPolicy.RUNTIME)@Component@Documentedpublic @interface Module { /** * 該模塊的key * 在設(shè)置模塊的key的時(shí)候，在同一個(gè)服務(wù)里面（同一個(gè)根節(jié)點(diǎn)），如果兩個(gè)類設(shè)置的key是一樣，最后會(huì)被去重為一個(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ù)將拋出異常無法啟動(dòng)， * @return */ Class parentModule(); /** * 該模塊名稱 * @return */ String moduleName(); /** * 模塊描述，一個(gè)該模塊詳細(xì)的描述 * @return */ String moduleRemark() default ""; /** * 能否被剪枝，你是可以設(shè)置模塊能不能被剪枝，默認(rèn)是不可以的（后續(xù)會(huì)根據(jù)數(shù)量對(duì)比情況進(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ù)邏輯}每個(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í), 不會(huì)收到\"該條碼對(duì)應(yīng)多個(gè)商品，請(qǐng)打印商品標(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)@Documentedpublic @interface ModuleConfig { /** * 配置的key */ String configKey(); /** * 配置名稱 * @return */ String configName(); /** * 配置描述，鼠標(biāo)懸浮時(shí)的氣泡提示 * @return */ String configRemark() default ""; /** * 是否必要，必要的不可以被剪枝 * @return */ boolean cutAble() default false;}@Target({ElementType.FIELD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @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會(huì)自動(dòng)給你尋找組件 * @return */ String customScopeType() default ""; /** * 對(duì)位文本類型的配置，min則為文本長度限制的最小值 * 對(duì)于數(shù)字類型的配置，min則為數(shù)字的最小值。 */ int min() default Integer.MIN_VALUE; /** * 對(duì)位文本類型的配置，min則為文本長度限制的最大值 * 對(duì)于數(shù)字類型的配置，min則為數(shù)字的最大值。 */ int max() default Integer.MAX_VALUE;}TMF 是 Trade Modularization Framework 的全稱，即交易模塊化框架，最初是交易系統(tǒng)中的一個(gè)代碼模塊，后來剔除業(yè)務(wù)耦合部分，獨(dú)立出來成為一個(gè)實(shí)現(xiàn)業(yè)務(wù)與平臺(tái)分離的業(yè)務(wù)框架。
5.2TMF架構(gòu)圖片
（圖片來源：https://www.cnblogs.com/shoshana-kong/p/14957739.html）
5.3 TMF2在架構(gòu)設(shè)計(jì)上主要的思想業(yè)務(wù)包與平臺(tái)分離的插件化架構(gòu)：平臺(tái)提供插件包注冊(cè)機(jī)制，實(shí)現(xiàn)業(yè)務(wù)方插件包在運(yùn)行期的注冊(cè)。業(yè)務(wù)代碼只允許存在于插件包中，與平臺(tái)代碼嚴(yán)格分離。業(yè)務(wù)包的代碼配置庫也與平臺(tái)的代碼庫分離，通過二方包的方式，提供給容器加載。全鏈路統(tǒng)一的業(yè)務(wù)身份：平臺(tái)需要能有按“業(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)行期動(dòng)態(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í)行。圖片
（圖片來源：https://www.infoq.cn/article/w3ztwqs9q4astbksd0mj）
5.4MTDD VS TMF圖片
6、MTDD 展望6.1 將模塊間的耦合度進(jìn)行量化前面有提到“持續(xù)重構(gòu)”這個(gè)概念；但是持續(xù)重構(gòu)提出來很容易，但是做起來，就沒有這么簡單；
What：首先是如何發(fā)現(xiàn)需要重構(gòu)的點(diǎn)，為什么是這個(gè)點(diǎn)要重構(gòu)，而不是那個(gè)點(diǎn)要重構(gòu)。
When：其實(shí)是什么時(shí)候需要進(jìn)行重構(gòu)。
為了更好的回答上面兩個(gè)問題，個(gè)人認(rèn)為最重要的是能夠量化兩個(gè)模塊的復(fù)雜度。
?：高內(nèi)聚低耦合，但是耦合度到底高還是低，如何衡量。想要衡量，就需要做到數(shù)據(jù)化，指標(biāo)化。
6.2 將模塊間的耦合度進(jìn)行可視化圖片
標(biāo)簽：
