分享：嘗試構建輕量級架構設計工具

輕量級架構設計工具

首先，咱們再來總結下構件模型的抽象結構，結構以下圖所示：

​

每一個業務領域下均可能有一到多個裝配模板用於設計產品；裝配模板則由若干個構件組成，產品的組裝式開發就表達爲構件與模板間的對應關係，能夠在構件中記錄複用推薦度，以方便後續作設計時使用；構件中會對應多個參數，參數儘可能使用數據模型中的數據項，可是實際操做中也可能須要列入一些與業務無關的技術字段，此外，應該給每一個參數註明是否爲可裝配參數，不可裝配的參數不提供面向業務人員的配置功能；一個構件對應一到多個實際的服務，構件此時表明的是一個服務集合，所謂複用不是任意去複用構件對應的服務，而是這些服務總體對外提供一個能力，這纔是「零件」的含義，不然，構件就不是一個真實的存在，若是原有構件中的一部分服務又被集合成了新的能力，則應再增長一個構件進行對應；服務因爲能夠被調用，所以會對應報文，既包括請求報文也包括響應報文，報文中又會包含構件對應的參數，兩者能夠合二爲一，也能夠分開表達；裝配模板在生產中，通過賦值產生可售產品；每一個可售產品又會有描述性的屬性信息，這些信息的集合就造成了產品目錄。以上就是構件模型的邏輯關係，基於這個邏輯關係，結合系統設計原理，能夠造成一個輕量級的架構設計和管控工具，其邏輯示意圖以下：

從系統設計原理的角度來說，系統的設計主要關注行爲和數據兩個方面，金融領域中，系統設計主要是爲了實現產品，所以，系統是爲了支持一到多個產品而存在的，系統及其支持的產品是用戶視角的系統可見部分；過渡到設計部分，可售產品由裝配模板配置而成，裝配模板其實是一種領域模型，不一樣領域的產品可能差別較大；裝配模板之下是構件，構件表明了一個領域的具體組成部分，是「零件」，構件中包含數據，也就是參數；這些又進一步分解爲服務，服務實際上既包含了行爲，又包含了對應的數據，「微服務」在設計上尤爲如此，服務做爲設計上的底層核心元素，能夠從統計角度包含歸屬組件、歸屬系統、歸屬用例、語言類型、代碼行數、原初開發或累積的人月數、歸屬團隊等等可用於項目管理的信息，其中有些信息能夠經過工具和配置信息得到，有些須要人工維護，可是其所累積起的項目信息庫對於大型企業的項目管理而言很是有價值。進一步將其工具化後，能夠基於構件模型創建起一個從業務直通深層實現的輕量級架構工具。

該工具優點以下：

1. 便於業務人員理解深層設計，從而加大業務人員參與度，提高業務與技術的融合；
2. 可以有效表達系統的可組裝程度和組裝方式，加快需求分析、定位和設計的速度，提升溝通效率，尤爲是對於跨組件、跨部門、跨團隊的設計；
3. 經過對底層服務的詳細描述，能夠累積項目自身的數據信息，便於進行快速的成本測算、可行性評估，項目預算其實一直是大企業的困擾，缺少有效的估算方式，又難以結構化地利用歷史數據，經過這種方式，將成本分攤到細節開發元素，可以提高評估的準確性，減小項目預估結果的波動性，再基於實際支出狀況不斷調整，能夠逐漸提高其精確性。

不足之處，顯然，須要投入必定精力去維護，不過這種精力上的支出應該是與項目同步付出的，不要搞成後補之類的處理方式。

應用場景設想

做爲架構設計和管控工具，天然要經過它去分析和管理新需求，經過上節的介紹，構件模型能夠造成新的流程表達方式，不一樣於業務模型是基於角色和職責，構件模型基於系統結構和關係，經過一條順序流「串」起構件，造成完整的業務處理過程，所以，新需求能夠快速定位到系統的修改位置，若是是須要新增構件，則很容易能夠定位到須要增長構件的位置，分析新構件與原有構件的關係，最重要的是，這一切能夠很方便地由產品經理、業務人員完成，並加快業務人員和技術人員的溝通速度。過程示意圖以下：

模型最重要的是造成通用語言，而語言最重要的練習方式是常用，要想常用則必須與行爲活動密切相關，因此，模型必須與設計有緊密聯繫，纔可以被常用，使用越多則溝通越容易，也越被你們接受去用於溝通，溝通多了天然就通用了。

 獲取更多Java高級架構最新視頻， 加入Java進階架構交流羣：142019080。直接點擊連接加羣。https://jq.qq.com/?_wv=1027&k=5lXBNZ7