系統設計的核心作用是在業務現實世界和抽象的IT實現之間建立起一道橋梁。
與其他行業被物理特性限制所束縛不同，軟件世界可以變得無限龐大，而限制軟件發展的其實是人的認知能力。所有軟件設計服務的目標其實都是管理人的認知，是關于人有限的精力如何學習軟件中無限多的知識（Knowledge）的問題。
(資料圖片僅供參考)
軟件行業從傳統的瀑布開發模式，過渡到了敏捷開發模式，對于文檔，敏捷宣言中說的是“工作的軟件高于詳盡的文檔”，但實際工作中開發人員寫的文檔是越來越少，或者是能不寫就不寫；流程上，更是恨不得需求還沒有出來就直接擼代碼，擼完代碼就直接上線。
缺乏整體系統設計，設計出來的系統就不夠完善，再加上快速的系統迭代，導致系統越來越難以維護，開發成本越來越高，一個項目需要參與的人越來越多，最終沒有人能夠說明清楚，這個系統具體是如何運行的了。隨著團隊人員的更替，加上每個人的設計思路又不一樣，更加加重了系統的復雜性。
上面也就引入了兩個問題：
缺乏文檔問題：不清楚系統長什么樣？軟件復雜度高的問題：迭代修改系統的成本高。上面兩個問題在MTDD都有相應的解法，后面我們會詳細講述，接下來我還是再詳談一下軟件復雜度。
2、軟件復雜度2.1 軟件復雜度的癥狀和原因《軟件設計哲學》這本書中提到，軟件復雜度的三種癥狀：
變化放大：需要修改一個地方，卻發現改動的點涉及全站，導致難度倍增；認知負荷：開發者需要完成一項任務的知識量；未知：開發者在修改代碼后，不知道它的實際影響面。為了從源頭上解決這些問題，John Ousterhout教授提出：從項目一開始就要嚴格遵循進行軟件設計的原則，那些為了趕工期而沒有經過良好設計的代碼，最終經過多次迭代后，都會變得越來越臃腫，繼而變得再也無法維護了。
我非常認可John Ousterhout的觀點，但
實際操作中發現基本不具有可行性，原因：
.從瀑布模式到敏捷開發，已經很難回去了。是否遵循良好的軟件設計原則很難衡量。沒有這么多的時間來檢查（代碼review，設計renview）是否有按照這些原則來設計和編碼。我的觀點
對于“簡化模塊依賴”，“減少模糊性”，“高內聚低耦合”這些原則的話術，知道的人就知道怎么做，不知道的人還是不知道怎么做。這些術語缺少實際的指導性。
2.2 軟件復雜度是怎么引入的（另外一個角度）2.2.1 我們來看一個例子圖片
2.2.2 系統到底是誰做出來的一個有意思的現象：
圖片
那系統到底是誰做出來的呢？（這里主要說的是業務系統。一些中間件之類的系統，基本都都由研發來完成的。）
圖片
系統設計離不開，業務人員、產品經理以及技術研發的合作，業務和產品的需求沒有理清楚，同樣會導致系統復雜度提升。
2.2.3 另外一種系統復雜度引入環節圖片
系統各主要相關方缺乏對系統設計的信息拉齊，給系統復雜度的提升同樣有重要的貢獻。
那么如何讓各角色更好的進行信息對齊，這就引入了MTDD。
3、一種新型的系統設計解決方案：MTDD前面提到了《軟件設計哲學》作者提出了一些系統設計總結，也有些人提出了一些方法論，比如領域驅動設計（DDD），測試驅動開發（TDD），行為驅動開發（BDD）；但是這些模式，都是從設計方法論上給與指導，戰術上指導偏少。下面我們來介紹我自己沉淀的一個方法論，和戰術指導MTDD&MTDP。
3.1 MTDD是什么MTDD的全稱是：Module Tree Drive Design, 模塊樹驅動設計，也可以叫做能力樹驅動設計。MTDD是一種系統設計模式，并同時提供了戰術層的SDK。
MTDD主要思想是讓業務，產品、研發共同對復雜業務系統中的模塊進行分析，并對這些業務模塊做好分層分類，最終形成各方達成一致的一棵模塊樹；研發人員開發可以通過給定的SDK，將系統中的代碼按照模塊的方式進行打標分類，系統根據代碼中打標分類，自動生成一顆可視化的模塊樹。通過這個方式，讓系統與業務保持高度一致。
MTDD從某個方面說也是DDD領域驅動設計中所宣導的統一語言一種實現方式。 |
MTDD思想主要體現在：
當業務和產品需要對系統能力進行新增、修改、或者擴展時，可以對照系統這顆可視化的模塊樹進行溝通，然后進行思考和設計具體的哪個或者哪些模塊需要進行修改或者擴展，并產出修改后的最終結果。研發人員接到接到需求后開發完成后，新開發的功能就會自動的在系統的模塊樹上進行呈現。產品和業務驗收時，就可以對照系統上的模塊樹，進行功能驗收。3.2 MTDD的特點3.2.1 模塊化在系統設計中，模塊是指一組相互依賴的程序元素，通常是在模塊內部完成特定的工作。模塊也可以被組合以形成更大的、更復雜的系統。子模塊則是模塊的一部分，通常是實現特定的功能。
在MTDD中， 模塊化更多的是從業務的角度上來說的，比如一個營銷觸達模塊，比如倉儲系統中的入庫模塊；模塊下面還可以有子模塊，子模塊也可以有子子模塊， 這個可以根據一定的顆粒度進行靈活拆分，重點是業務，產品、研發三方達成一致，并且明確模塊的關系（父子關系）。
3.2.2 分類與分層將模塊化的模板進行分層分類。
在系統設計中，分層和分類是非常重要的，這有助于提高系統的可擴展性和可維護性，也能很好的降低人的認知負荷。
OOD（面對對象設計）本質就是一種分類思想。DDD（領域驅動設計）本質也是一種分類思想。分層設計：
在現實世界中，所有我們見到的事物，人類都自然的對其給與了分層，比如：
圖片
再比如在倉儲管理中，也會有天然的分層：
圖片
分層分類-復雜度分解：
我們的目標是將一些同類型的提高一個抽象層次，將大腦比較難處理的9個概念簡化成3個，這樣就無需記憶其中的每個概念，另外由于較高層次的思想總是能夠提示下面一個層次的思想，所以記憶起來會更方便。所有的思維過程（思考、記憶、解決問題）都應該使用這樣的分組和概括的方法，將大腦中的無序信息組成一個相關關聯的金字塔結構。
每個模塊下又可以有多個子模塊。
總而言之，設計人員對模塊進行分層分類后，可以大大降低思考復雜度， 這個很好理解。
圖片
3.2.3可視化分層分類的模塊以樹狀接口進行可視化呈現。
右邊的圖是：研發實現產品需求后，系統自動生成的能力樹的樣子。
3.2.4 強大的配置化能力所有的業務配置，都是業務相關的，系統用來控制業務的邏輯，本質就是業務的一部分。在傳統的業務系統中一般有兩種方式來實現：
使用需要一個配置中心，配置中心一般都使用key-value的方式來存儲。業務系統根據配置的key到配置中心來獲取value，并解析value的值。業務人員直接在配置中心來做配置值的修改。每個配置單獨開發配置頁面，業務人員在配置頁面上進行值修改。這兩種方式都存在一些問題：
使用配置中心，雖然將所有的配置都進行了統一，但是面對一些負責配置時，需要采用類似json這種格式來存儲，修改的時候只能修改json的值，無法通過頁面富樣式頁面來修改。每個頁面單獨開發配置頁面，對配置友好，但是開發工作量大，因為每個配置都需要前端開發。使用MTDD配置化能力時，就可以解決上面兩個問題
業務配置一定屬于具體的業務模塊，因為配置是用戶控制某個具體的模塊邏輯，所以配置盡量掛在模塊下面是一個非常自然的做法。
我的觀點
業務配置一定屬于具體的業務模塊，因為配置是用戶控制某個具體的模塊邏輯，所以配置盡量掛在模塊下面是一個非常自然的做法。
3.2.5 其他優勢讓業務，產品，在提需求的時候，就能夠以系統能力的方式去思考。在有新需求時，產研可以方便的在能力樹上找到需要改動的模塊。測試的影響范圍也很容易確定。對修改友好，影響范圍可控。讓程序員天然的進行開閉原則，對新增開放，對修改改封閉。3.3 MTDD作用與總結系統設計的核心作用是在業務現實世界和抽象的IT實現之間建立起一道橋梁。而業務系統本身就是現實世界在計算機系統中的映射。
現實世界是一個模塊化的，層次化的樹狀結構，所以業務系統就應該自然的通過模塊化的樹狀結構來進行映射。
MTDD正是基于此，通過一個可視化的能力樹，這顆能力樹作為實實在在，可以看得見的橋梁，來拉齊業務、產品和系統研發。并最終做到讓業務和產品，可以真正以產品能力搭建的視角來規劃，設計系統模塊和系統功能。可以讓系統架構人員自然而然的進行高內聚，低耦合的系統設計，可以讓一線研發自然而然的進行模塊化編程。
模塊樹驅動設計閉環
圖片
4、MTDD實戰4.1 MTDD戰略層4.1.1 統一語言DDD中也有統一語言，或者叫做“通用語言（Ubiquitous Language ）”
當團隊成員不能享用一個公共語言來討論領域時，項目會面臨嚴重的問題。領域專家使用自己的行話，技術團隊成員在設計中也用自己的語言討論領域。
代碼可能是一個軟件項目中最重要的產物，但每天用來討論的術語卻與代碼中使用的術語脫節了。即使是同一個人都需要使用不同的 語言來交談和書寫，所以要想完成對領域的深刻表達通常需要產生 一種臨時形式，但這種形式不會出現在代碼甚至是書寫的內容中。
在交流的過程中，需要做翻譯才能讓其他的人理解這些概念。開發 人員可能會努力使用外行人的語言來解析一些設計模式，但這并一定都能成功奏效。領域專家也可能會創建一種新的行話以努力表達 他們的這些想法。在這個痛苦的交流過程中，這種類型的翻譯并不能對知識的構建過程產生幫助。
上面這段是話是摘自《領域驅動設計精簡版 》
Eric Evans 早就意識到，需要在領域專家和研發之間共用一套通用語言，并且Eric Evans也做了大量的舉例說明，來說明什么是通用語言，以及統一通用語言可以更好的服務于系統設計。
MTDD更也是站在巨人的肩膀上，提供了一個方法論：讓業務，產品，技術在系統設計之前，一起對照系統模塊樹來進行溝通；對于一個新功能，一起思考是在某個模塊下新增模塊，還是修改貨擴展模塊內部的邏輯；在對齊后，就可以進行開發了，并且研發有一定的范式開做開發，開發后，系統的模塊樹就能夠自動可視化的呈現出來；業務和產品也可以通過可視化的方式進行驗收；
4.1.2 按定制規范來做設計和開發上面說了在業務方、產品、技術在參照能力樹根據需求并對齊需要開發的模塊后，研發可以按照一定的范式做系統開發；這是因為我們提供了一套開發的SDK，以及SDK的使用文檔，來幫助研發人員來進行基于能力樹功能的開發。系統功能開發完成后，相應的模塊信息就可以自動在模塊樹頁面上進行呈現。當然想要在頁面上進行呈現，需要有前端來支持。
這個規范主要由幾個主要的java注解來實現：
@Module@ModuleConfig@ConfigItem4.1.3系統的模塊化以及分層分類
使用上面的java注解，對代碼中模塊進行打標。
業務模塊化，并且做了分層與分類，那么系統中的代碼需要根據業務中的分層分類進行進行分類打標，使其與業務分層分類保持一致。
4.1.4 持續重構（Continue Refactor）我們這個世界夠復雜了吧，如果讓你設計一個IT系統來實現刻畫這個世界的方方面面，我打賭一定沒有人搞得定；但現實中的這個世界還是能夠有條不紊的發展演進，沒有需要出現“推倒重來”的現象，為什么呢， 我認為是我們的世界一直在用各種方式不停的重構。
“物競天擇，適者生存”出自達爾文的進化論，達爾文在1859年出版的《物種起源》一書中系統地闡述了他的進化學說。物競天擇，適者生存是指物種之間及生物內部之間相互競爭，物種與自然之間的抗爭，能適應自然者被選擇存留下來的一種叢林法則。
對于軟件系統也是這樣，業務是在不停的發展， 我們的認知也是一直不斷的更新，當“我們”通過可視化的能力樹發現一些突兀時，那肯定是某個或者某些模塊拆分不正確，或者模塊提供的能力不合適，這時，我們就可以考慮對模塊樹進行重構了，要么是拆分模塊，要么是調整模塊的關系，要么是修改模塊的職責。
4.1.5關于產品需求如果產品了解MTDD，那么就會提出更加符合產品化的需求了
如果研發對MTDD理解深入，那么當產品的需求不符合產品化，能力化時，就會與產品進行溝通，產品修改需求，以便更好的設計出產品化，系統能力化的需求。
?好的產品需求 | ×不好的產品需求 |
| 對現有系統能力的擴展增加新的系統能力 | 針對特定的業務需求 定制系統能力 |
MTDP的全稱是Module Tree Drive Programing, 領域樹驅動編程。
4.2.1模塊注解@Module的定義
/** * * 模塊注解，打在一個服務類上，Module注解是繼承了Component注解，因此它注解的類可以被實例化到Spring中去 * 服務啟動時會掃碼所有Module類，將他們組裝成樹進行持久化。 */@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE})@Retention(RetentionPolicy.RUNTIME)@Component@Documentedpublic @interface Module { /** * 該模塊的key * 在設置模塊的key的時候，在同一個服務里面（同一個根節點），如果兩個類設置的key是一樣，最后會被去重為一個模塊，無論是單體服務還是分布式工程。 * moduleKey全局唯一，就算它們歸屬不同的根節點，也不能設置一樣的moduleKey， * 不同根節點的模塊，如果設置了同一個moduleKey，后部署的服務將無法能力樹的變更情況進行持久化。 * @return */ String moduleKey(); /** * 用于指定該模塊的父模塊， * 根節點的parentModule指定為 {@link Void}.class。 * 每個模塊指定他們的夫模塊，直到可達根節點，最后生成一顆樹。 * 指定parentModule時一定要注意，不能循環依賴了，循環依賴的情況下，服務將拋出異常無法啟動， * @return */ Class parentModule(); /** * 該模塊名稱 * @return */ String moduleName(); /** * 模塊描述，一個該模塊詳細的描述 * @return */ String moduleRemark() default ""; /** * 能否被剪枝，你是可以設置模塊能不能被剪枝，默認是不可以的（后續會根據數量對比情況進行調整默認值）。 * 我們應該將系統中必要的功能設置為無法裁減，將那些加強性的能力，智能化的能力，衍生化的能力，非基本的能力設置為可以裁減 * @return */ boolean cutAble() default false;}模塊的具體例子：
@Module(moduleKey = "scm.wms", moduleName = "WMS", parentModule = NULL)public class WmsModule { //業務邏輯}@Module(moduleKey = "scm.wms.inner.test1", moduleName = "測試模塊1", parentModule = WmsModule.class)public class InnerTestModule1 { //業務邏輯}@Module(moduleKey = "scm.wms.inner.test2", moduleName = "測試模塊2", parentModule = WmsModule.class)public class InnerTestModule2 { //業務邏輯}每個模塊都有父模塊ParentModule，跟模塊的父模塊為NULL，模塊樹則是由所有模塊組成的一個樹狀結構的樹。
圖片
4.2.3 裁剪與恢復圖片
4.2.4 模塊配置找到模塊上的配置，點擊展開配置
圖片
展開配置如下：
圖片
上面的配置，是無需前端進行開發，只需要后端實現就好，后端代碼：
@Data@ModuleConfig(configKey = "scm.wms.inbound.receive.oneBarcodeMuliSku", configName = "收貨一碼多品配置", module="scm.wms.inbound.receive")public class ReceiveScanOneCodeMoreSkuModuleConfig { @ConfigItem(itemName = "是否開啟一碼多品的攔截" , itemRemark = "如果關閉, 一碼多品的商品在收貨時, 不會收到\"該條碼對應多個商品，請打印商品標簽\"的提醒, prd:https://poizon.feishu.cn/wiki/wikcnstRj3Qfbn4fXDrmvBk6R0d" , defaultValue = "true") private Boolean isOpen; @ConfigItem(itemName = "攔截方式" , itemRemark = "如果配置強攔截，則必須打印商品標簽, 阻斷收貨流程。如果配置弱攔截, 只是提醒一下, 不阻斷收貨流程" , scopeClass = InterceptType.class , defaultValue = "WEAK") private String interceptType; @ConfigItem(itemName = "攔截規則" , scopeClass = InterceptRuleType.class , defaultValue = "ARBITRARY") private String interceptRule;}配置的幾個java注解：
ModuleConfig/** * 業務配置注解，業務配置是Module的字段 */@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface ModuleConfig { /** * 配置的key */ String configKey(); /** * 配置名稱 * @return */ String configName(); /** * 配置描述，鼠標懸浮時的氣泡提示 * @return */ String configRemark() default ""; /** * 是否必要，必要的不可以被剪枝 * @return */ boolean cutAble() default false;}@Target({ElementType.FIELD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface ConfigItem { /** * 配置名稱 * @return */ String itemName(); /** * 配置描述，鼠標懸浮時的氣泡提示 * @return */ String itemRemark() default ""; /** * 默認值 * @return */ String defaultValue() default ""; /** * 如果你的取值范圍是枚舉指定枚舉的全路徑類名, * 如果你的取值范圍是一種策略，指定策略的interfaces的全路徑名稱 * @return */ Class scopeClass() default Void.class; /** * 范圍，默認通用，當你需要定制時才需要指定 * @return */ ScopeType scopeType() default ScopeType.COMMON; /** * 自定義組件，需要前端參與開發，非特殊組件，無需設置，DSK會自動給你尋找組件 * @return */ String customScopeType() default ""; /** * 對位文本類型的配置，min則為文本長度限制的最小值 * 對于數字類型的配置，min則為數字的最小值。 */ int min() default Integer.MIN_VALUE; /** * 對位文本類型的配置，min則為文本長度限制的最大值 * 對于數字類型的配置，min則為數字的最大值。 */ int max() default Integer.MAX_VALUE;}TMF 是 Trade Modularization Framework 的全稱，即交易模塊化框架，最初是交易系統中的一個代碼模塊，后來剔除業務耦合部分，獨立出來成為一個實現業務與平臺分離的業務框架。
5.2TMF架構圖片
（圖片來源：https://www.cnblogs.com/shoshana-kong/p/14957739.html）
5.3 TMF2在架構設計上主要的思想業務包與平臺分離的插件化架構：平臺提供插件包注冊機制，實現業務方插件包在運行期的注冊。業務代碼只允許存在于插件包中，與平臺代碼嚴格分離。業務包的代碼配置庫也與平臺的代碼庫分離，通過二方包的方式，提供給容器加載。全鏈路統一的業務身份：平臺需要能有按“業務身份”進行業務與業務之間邏輯隔離的能力，而不是傳統SPI架構不區分業務身份，簡單過濾的方式。如何設計這個業務身份，也成為業務間隔離架構的關鍵。管理域與運行域分離：業務邏輯不能依靠運行期動態計算，要能在靜態期進行定義并可視化呈現。業務定義中出現的規則疊加沖突，也在靜態器進行沖突決策。在運行期，嚴格按照靜態器定義的業務規則、沖突決策策略執行。圖片
（圖片來源：https://www.infoq.cn/article/w3ztwqs9q4astbksd0mj）
5.4MTDD VS TMF圖片
6、MTDD 展望6.1 將模塊間的耦合度進行量化前面有提到“持續重構”這個概念；但是持續重構提出來很容易，但是做起來，就沒有這么簡單；
What：首先是如何發現需要重構的點，為什么是這個點要重構，而不是那個點要重構。
When：其實是什么時候需要進行重構。
為了更好的回答上面兩個問題，個人認為最重要的是能夠量化兩個模塊的復雜度。
?：高內聚低耦合，但是耦合度到底高還是低，如何衡量。想要衡量，就需要做到數據化，指標化。
6.2 將模塊間的耦合度進行可視化圖片
標簽：
