一、前言

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

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

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

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

上面也就引入了兩個問題：

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

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

2、軟件復(fù)雜度

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

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

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

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

我非常認可John Ousterhout的觀點，但

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

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

我的觀點

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

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

2.2.1 我們來看一個例子

圖片

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

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

圖片

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

圖片

系統(tǒng)設(shè)計離不開，業(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è)計的信息拉齊，給系統(tǒng)復(fù)雜度的提升同樣有重要的貢獻。

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

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

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

3.1 MTDD是什么

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

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

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

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

3.2 MTDD的特點

3.2.1 模塊化

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

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

3.2.2 分類與分層

將模塊化的模板進行分層分類。

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

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

分層設(shè)計：

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

圖片

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

圖片

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

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

每個模塊下又可以有多個子模塊。

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

圖片

3.2.3 可視化

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

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

3.2.4 強大的配置化能力

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

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

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

1. 使用配置中心，雖然將所有的配置都進行了統(tǒng)一，但是面對一些負責(zé)配置時，需要采用類似json這種格式來存儲，修改的時候只能修改json的值，無法通過頁面富樣式頁面來修改。
2. 每個頁面單獨開發(fā)配置頁面，對配置友好，但是開發(fā)工作量大，因為每個配置都需要前端開發(fā)。

使用MTDD配置化能力時，就可以解決上面兩個問題

業(yè)務(wù)配置一定屬于具體的業(yè)務(wù)模塊，因為配置是用戶控制某個具體的模塊邏輯，所以配置盡量掛在模塊下面是一個非常自然的做法。

我的觀點

業(yè)務(wù)配置一定屬于具體的業(yè)務(wù)模塊，因為配置是用戶控制某個具體的模塊邏輯，所以配置盡量掛在模塊下面是一個非常自然的做法。

3.2.5 其他優(yōu)勢

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

3.3 MTDD作用與總結(jié)

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

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

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

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

圖片

4、MTDD實戰(zhàn)

4.1 MTDD戰(zhàn)略層

4.1.1 統(tǒng)一語言

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

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

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

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

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

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

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

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

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

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

• @Module
• @ModuleConfig
• @ConfigItem

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

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

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

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

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

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

對于軟件系統(tǒng)也是這樣，業(yè)務(wù)是在不停的發(fā)展， 我們的認知也是一直不斷的更新，當(dāng)“我們”通過可視化的能力樹發(fā)現(xià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)品化，能力化時，就會與產(chǎn)品進行溝通，產(chǎn)品修改需求，以便更好的設(shè)計出產(chǎn)品化，系統(tǒng)能力化的需求。

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

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

4.2.1 模塊

注解@Module的定義

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


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


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

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

圖片

4.2.3 裁剪與恢復(fù)

圖片

4.2.4 模塊配置

找到模塊上的配置，點擊展開配置

圖片

展開配置如下：

圖片

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

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

配置的幾個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)懸浮時的氣泡提示
     * @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)懸浮時的氣泡提示
     * @return
     */
    String itemRemark() default "";
    /**
     * 默認值
     * @return
     */
    String defaultValue() default "";
    /**
     * 如果你的取值范圍是枚舉指定枚舉的全路徑類名,
     * 如果你的取值范圍是一種策略，指定策略的interfaces的全路徑名稱
     * @return
     */
    Class<?> scopeClass() default Void.class;
    /**
     * 范圍，默認通用，當(dāng)你需要定制時才需要指定
     * @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)中的一個代碼模塊，后來剔除業(yè)務(wù)耦合部分，獨立出來成為一個實現(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è)計上主要的思想

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

圖片

（圖片來源：https://www.infoq.cn/article/w3ztwqs9q4astbksd0mj）

5.4 MTDD VS TMF

圖片

6、MTDD 展望

6.1 將模塊間的耦合度進行量化

前面有提到“持續(xù)重構(gòu)”這個概念；但是持續(xù)重構(gòu)提出來很容易，但是做起來，就沒有這么簡單；

What：首先是如何發(fā)現(xiàn)需要重構(gòu)的點，為什么是這個點要重構(gòu)，而不是那個點要重構(gòu)。

When：其實是什么時候需要進行重構(gòu)。

為了更好的回答上面兩個問題，個人認為最重要的是能夠量化兩個模塊的復(fù)雜度。

?：高內(nèi)聚低耦合，但是耦合度到底高還是低，如何衡量。想要衡量，就需要做到數(shù)據(jù)化，指標(biāo)化。

6.2 將模塊間的耦合度進行可視化

圖片