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