上一篇介紹了通過構件模型支持組裝式設計的思路，本節再講講將其應用於構建輕量級架構設計工具的思路。
輕量級架構設計工具
首先，我們再來總結下構件模型的抽象結構，結構如下圖所示：
每個業務領域下都可能有一到多個裝配模板用於設計產品；裝配模板則由若干個構件組成，產品的組裝式開發就表達爲構件與模板間的對應關係，可以在構件中記錄複用推薦度，以方便後續做設計時使用；構件中會對應多個參數，參數儘量使用數據模型中的數據項，但是實際操作中也可能需要列入一些與業務無關的技術字段，此外，應該給每個參數註明是否爲可裝配參數，不可裝配的參數不提供面向業務人員的配置功能；一個構件對應一到多個實際的服務，構件此時代表的是一個服務集合，所謂複用不是任意去複用構件對應的服務，而是這些服務整體對外提供一個能力，這纔是“零件”的含義，否則，構件就不是一個真實的存在，如果原有構件中的一部分服務又被集合成了新的能力，則應再增加一個構件進行對應；服務由於可以被調用，因此會對應報文，既包括請求報文也包括響應報文，報文中又會包含構件對應的參數，二者可以合二爲一，也可以分開表達；裝配模板在生產中，經過賦值產生可售產品；每個可售產品又會有描述性的屬性信息，這些信息的集合就形成了產品目錄。以上就是構件模型的邏輯關係，基於這個邏輯關係，結合系統設計原理，可以形成一個輕量級的架構設計和管控工具，其邏輯示意圖如下：
從系統設計原理的角度來講，系統的設計主要關注行爲和數據兩個方面，金融領域中，系統設計主要是爲了實現產品，因此，系統是爲了支持一到多個產品而存在的，系統及其支持的產品是用戶視角的系統可見部分；過渡到設計部分，可售產品由裝配模板配置而成，裝配模板實際上是一種領域模型，不同領域的產品可能差異較大；裝配模板之下是構件，構件代表了一個領域的具體組成部分，是“零件”，構件中包含數據，也就是參數；這些又進一步分解爲服務，服務實際上既包含了行爲，又包含了對應的數據，“微服務”在設計上尤其如此，服務作爲設計上的底層核心元素，可以從統計角度包含歸屬組件、歸屬系統、歸屬用例、語言類型、代碼行數、原初開發或累積的人月數、歸屬團隊等等可用於項目管理的信息，其中有些信息可以通過工具和配置信息獲得，有些需要人工維護，但是其所累積起的項目信息庫對於大型企業的項目管理而言非常有價值。進一步將其工具化後，可以基於構件模型建立起一個從業務直通深層實現的輕量級架構工具。
該工具優勢如下：
- 便於業務人員理解深層設計，從而加大業務人員參與度，提升業務與技術的融合；
- 能夠有效表達系統的可組裝程度和組裝方式，加快需求分析、定位和設計的速度，提高溝通效率，尤其是對於跨組件、跨部門、跨團隊的設計；
- 通過對底層服務的詳細描述，可以累積項目自身的數據信息，便於進行快速的成本測算、可行性評估，項目預算其實一直是大企業的困擾，缺乏有效的估算方式，又難以結構化地利用歷史數據，通過這種方式，將成本分攤到細節開發元素，能夠提升評估的準確性，減少項目預估結果的波動性，再基於實際支出情況不斷調整，可以逐漸提升其精確性。
不足之處，顯然，需要投入一定精力去維護，不過這種精力上的支出應該是與項目同步付出的，不要搞成後補之類的處理方式。
應用場景設想
作爲架構設計和管控工具，自然要通過它去分析和管理新需求，通過上節的介紹，構件模型可以形成新的流程表達方式，不同於業務模型是基於角色和職責，構件模型基於系統結構和關係，通過一條順序流“串”起構件，形成完整的業務處理過程，因此，新需求可以快速定位到系統的修改位置，如果是需要新增構件，則很容易可以定位到需要增加構件的位置，分析新構件與原有構件的關係，最重要的是，這一切可以很方便地由產品經理、業務人員完成，並加快業務人員和技術人員的溝通速度。過程示意圖如下：
模型最重要的是形成通用語言，而語言最重要的練習方式是經常使用，要想經常使用則必須與行爲活動密切相關，所以，模型必須與設計有緊密聯繫，才能夠被經常使用，使用越多則溝通越容易，也越被大家接受去用於溝通，溝通多了自然就通用了。所以，一旦選擇了做企業級的業務模型、業務架構，則要記住《紅樓夢》中賈寶玉的“通靈寶玉”和薛寶釵的“金鎖”後邊的銘文：“莫失莫忘，仙壽恆昌；不離不棄，芳齡永繼”。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
中臺之上（九）：如何基於企業級業務架構管理業務需求？
中臺之上（十）：業務架構設計“笨重”，它能跟敏捷沾邊嗎？
中臺之上（十一）：企業級業務架構設計的“五難”
中臺之上（十二）：如何快速設計業務架構？
中臺之上（十三）：探討支持組裝式開發的業務架構設計方法
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。