作者：人月神話(huà)，新浪博客同名

今天介紹下組件化開(kāi)發(fā)方面的內(nèi)容，在前面我講解微服務(wù)的時(shí)候就已經(jīng)談到，實(shí)際上微服務(wù)本身就是傳統(tǒng)的業(yè)務(wù)系統(tǒng)組件化開(kāi)發(fā)的一個(gè)升級(jí)。懂得基礎(chǔ)的組件化開(kāi)發(fā)和技術(shù)架構(gòu)設(shè)計(jì)是也是過(guò)渡到當(dāng)前主流的微服務(wù)架構(gòu)思想的基礎(chǔ)。

組件化開(kāi)發(fā)概述

在這里先介紹和說(shuō)明下基于組件化開(kāi)發(fā)帶來(lái)的優(yōu)勢(shì)。

首先，原有到系統(tǒng)級(jí)的粗粒度控制細(xì)化到了組件級(jí)別的細(xì)粒度控制，一個(gè)復(fù)雜系統(tǒng)的構(gòu)建就是組件最終集成后的一個(gè)結(jié)果。每個(gè)組件都自己獨(dú)立的版本，組件可以獨(dú)立編譯、獨(dú)立打包和部署；

其次，產(chǎn)品組件化后可以真正實(shí)現(xiàn)完整意義上的按組件進(jìn)行產(chǎn)品配置和銷(xiāo)售，用戶(hù)可以選擇購(gòu)買(mǎi)哪些組件，組件之間可以靈活的進(jìn)行組裝。另外，包括諸如配置管理、開(kāi)發(fā)、測(cè)試、打包、發(fā)布完全控制到組件層面，會(huì)帶來(lái)其它很多好處，如果一個(gè)組件進(jìn)行小版本升級(jí)，提供給外部的接口沒(méi)有任何變動(dòng)，其它組件完全可以不用做任何測(cè)試。

組件化開(kāi)發(fā)思路在SOA之前已經(jīng)有成熟的組件化開(kāi)發(fā)方法，只是在SOA出現(xiàn)后，SOA咨詢(xún)、需求分析、設(shè)計(jì)實(shí)現(xiàn)方法論進(jìn)一步融入到組件化開(kāi)發(fā)中。各種底層基礎(chǔ)技術(shù)框架的發(fā)展和完善，為組件化開(kāi)發(fā)提供了根據(jù)完整的支持，推動(dòng)組件化開(kāi)發(fā)的發(fā)展，特別是在B/S架構(gòu)下的組件化開(kāi)發(fā)。

回到軟件生命周期，我們?cè)賮?lái)闡述下組件化開(kāi)發(fā)的核心思路和邏輯。

業(yè)務(wù)建模和業(yè)務(wù)組件階段

流程驅(qū)動(dòng)IT以及SOA思想的進(jìn)一步融合，再次改變?cè)械慕M件開(kāi)發(fā)重點(diǎn)關(guān)注技術(shù)組件層面的問(wèn)題。業(yè)務(wù)建模階段重點(diǎn)包括了業(yè)務(wù)架構(gòu)和數(shù)據(jù)架構(gòu)，其導(dǎo)入點(diǎn)仍然是端到端流程分析為主線導(dǎo)入。業(yè)務(wù)架構(gòu)分析重點(diǎn)就是形成業(yè)務(wù)組件，也可以叫業(yè)務(wù)模塊。

在這里重點(diǎn)還是業(yè)務(wù)組件的形成，要知道業(yè)務(wù)組件來(lái)源于流程分析和流程分解。業(yè)務(wù)組件本身就是高度內(nèi)聚的多個(gè)業(yè)務(wù)功能的一個(gè)集合，業(yè)務(wù)組件之間本身就是松耦合，業(yè)務(wù)組件通過(guò)交互和集成可以完成一個(gè)更大的端到端流程。業(yè)務(wù)組件的識(shí)別仍然回歸傳統(tǒng)的流程分析加面向結(jié)構(gòu)下面的CRUD矩陣分析等方法來(lái)分析高內(nèi)聚性。矩陣分析包括了業(yè)務(wù)功能和業(yè)務(wù)數(shù)據(jù)之間的CRUD關(guān)系，也包括了業(yè)務(wù)功能和業(yè)務(wù)功能之間本身的關(guān)聯(lián)和依賴(lài)性分析。

對(duì)于粗粒度的數(shù)據(jù)建模我們把它劃歸到業(yè)務(wù)建模階段，該階段的數(shù)據(jù)建模偏概念模型，后續(xù)在設(shè)計(jì)階段再轉(zhuǎn)化到物理模型和數(shù)據(jù)實(shí)體組件。同時(shí)該階段的數(shù)據(jù)建模需要梳理出業(yè)務(wù)和流程中核心的基礎(chǔ)主數(shù)據(jù)和核心業(yè)務(wù)單據(jù)，分析業(yè)務(wù)單據(jù)關(guān)聯(lián)映射關(guān)系，協(xié)助前面談到的CRUD矩陣分析。

在這個(gè)階段最終需要輸出的涉及到組件層面的產(chǎn)出物包括軟件系統(tǒng)的業(yè)務(wù)組件，每個(gè)業(yè)務(wù)組件包含的業(yè)務(wù)功能或叫業(yè)務(wù)用例。整個(gè)業(yè)務(wù)系統(tǒng)中的業(yè)務(wù)實(shí)體，業(yè)務(wù)實(shí)體關(guān)系圖等。

軟件需求階段

在這個(gè)階段不做詳細(xì)的說(shuō)明，但是我們?nèi)匀恍枰眄樥麄€(gè)關(guān)系，即首先形成業(yè)務(wù)組件，業(yè)務(wù)組件是大的業(yè)務(wù)模塊。業(yè)務(wù)組件下面有業(yè)務(wù)用例，這里的業(yè)務(wù)用例通過(guò)進(jìn)一步的需求分析和開(kāi)發(fā)，將業(yè)務(wù)用例轉(zhuǎn)換為系統(tǒng)用例，然后對(duì)每一個(gè)系統(tǒng)用例進(jìn)行詳細(xì)的描述。業(yè)務(wù)流程-》業(yè)務(wù)組件-》系統(tǒng)用例是一個(gè)從上向下，逐層展開(kāi)的一個(gè)分析過(guò)程。

在傳統(tǒng)的用例建模中，我們沒(méi)太關(guān)注用例之間的交互，而將其延后到設(shè)計(jì)和實(shí)現(xiàn)階段去完成?，F(xiàn)在來(lái)看該工作需要提前，即從全系統(tǒng)來(lái)看，首先完成對(duì)業(yè)務(wù)組件之間交互的描述，對(duì)交互點(diǎn)和交互場(chǎng)景進(jìn)行詳細(xì)說(shuō)明。在細(xì)化進(jìn)入到一個(gè)業(yè)務(wù)組件內(nèi)部后，需要對(duì)系統(tǒng)用例之間的相互調(diào)用進(jìn)行描述。

對(duì)于數(shù)據(jù)層面則在軟件需求階段進(jìn)一步細(xì)化，從概念模型階段過(guò)渡到邏輯模型階段，進(jìn)一步細(xì)化業(yè)務(wù)功能為系統(tǒng)操作，分析系統(tǒng)操作和數(shù)據(jù)對(duì)象之間的關(guān)系。

系統(tǒng)建模和技術(shù)組件階段

這個(gè)階段即傳統(tǒng)的架構(gòu)設(shè)計(jì)階段，我們?nèi)匀皇墙M件化開(kāi)發(fā)的一個(gè)重點(diǎn)，這里的系統(tǒng)建模和架構(gòu)設(shè)計(jì)重點(diǎn)都變化為功能性架構(gòu)。但是前面業(yè)務(wù)建模階段已經(jīng)有前期的積累。如果是業(yè)務(wù)建模階段是系統(tǒng)分析的話(huà)，那么系統(tǒng)建模階段是系統(tǒng)設(shè)計(jì)。

系統(tǒng)建模階段第一個(gè)重點(diǎn)是要實(shí)現(xiàn)從業(yè)務(wù)組件到技術(shù)組件的細(xì)化。在前述對(duì)SOA的分析中我們提到業(yè)務(wù)組件、服務(wù)組件和技術(shù)組件。在這里我們只談業(yè)務(wù)組件和技術(shù)組件，并弱化服務(wù)組件的概念。首先，進(jìn)入了架構(gòu)分層后，一個(gè)業(yè)務(wù)組件可能需要拆分為多個(gè)技術(shù)組件，包括數(shù)據(jù)層組件、邏輯層組件、UI層組件、數(shù)據(jù)實(shí)體組件等。其次，在該階段我們會(huì)引入很多的純技術(shù)層面的組件，這些技術(shù)層面組件和業(yè)務(wù)完全無(wú)關(guān)而和平臺(tái)非功能性架構(gòu)有關(guān)，如安全、異常、日志等相關(guān)組件等。

業(yè)務(wù)組件本身符合高內(nèi)聚性，轉(zhuǎn)換到技術(shù)組件后仍然需要符合高內(nèi)聚性，技術(shù)組件之間其一不允許出現(xiàn)相互交叉調(diào)用；其二整個(gè)調(diào)用關(guān)系應(yīng)該是從上層往下層調(diào)用。縱向看是UI組件->邏輯層組件->數(shù)據(jù)層組件調(diào)用關(guān)系；而橫向看則是同層之間的各個(gè)技術(shù)組件之間存在相互調(diào)用關(guān)系。按照組件最大化復(fù)用原則，優(yōu)先考慮UI組件復(fù)用，其次考慮邏輯層復(fù)用，最后才考慮數(shù)據(jù)層復(fù)用。

根據(jù)前面分析可以很明顯的看到在系統(tǒng)建模階段關(guān)于組件分析和設(shè)計(jì)的幾個(gè)重點(diǎn)內(nèi)容：其一是業(yè)務(wù)組件轉(zhuǎn)換為技術(shù)組件，并按層分解；其二是根據(jù)業(yè)務(wù)交互，用例交互分析組件之間的調(diào)用關(guān)系。這些調(diào)用關(guān)系就是組件間的接口，通過(guò)業(yè)務(wù)和流程分析的方法來(lái)找到接口，轉(zhuǎn)到相關(guān)組件的接口設(shè)計(jì)上，組件之間的調(diào)用只能通過(guò)接口，組件內(nèi)部完全黑盒；其三是數(shù)據(jù)建模和設(shè)計(jì)，將前面數(shù)據(jù)建模分析內(nèi)容轉(zhuǎn)換為數(shù)據(jù)實(shí)體組件，數(shù)據(jù)實(shí)體組件只含數(shù)據(jù)實(shí)體，實(shí)現(xiàn)控制類(lèi)和實(shí)體類(lèi)的分離。這樣數(shù)據(jù)實(shí)體類(lèi)容易變化為下層可以被多個(gè)邏輯層技術(shù)組件引用的組件。

這個(gè)階段在傳統(tǒng)的架構(gòu)設(shè)計(jì)文檔上，可以看到需要輸出的內(nèi)容包括了業(yè)務(wù)組件->技術(shù)組件的對(duì)應(yīng)清單，組件調(diào)用關(guān)系和依賴(lài)關(guān)系圖，組件接口設(shè)計(jì)文檔和接口清單，可復(fù)用組件抽取和分析，組件包視圖和部署視圖，整個(gè)應(yīng)用系統(tǒng)的組件化后的產(chǎn)品結(jié)構(gòu)視圖和配置項(xiàng)清單等。

實(shí)現(xiàn)階段

實(shí)現(xiàn)階段我們關(guān)注的問(wèn)題是一個(gè)技術(shù)平臺(tái)或框架支持組件化開(kāi)發(fā)、測(cè)試和部署。傳統(tǒng)的B/S架構(gòu)開(kāi)發(fā)我們比較難以解決的問(wèn)題是UI層內(nèi)容的獨(dú)立打包和部署，而當(dāng)前在新的微服務(wù)架構(gòu)和前后端分離開(kāi)發(fā)框架下，已經(jīng)可以完全做到前端和后端單獨(dú)打包和部署。

可以單獨(dú)對(duì)組件進(jìn)行自動(dòng)化的單元測(cè)試，當(dāng)某個(gè)組件有變化的時(shí)候，可以單獨(dú)對(duì)變化的組件進(jìn)行版本升級(jí)，單獨(dú)對(duì)變化組件進(jìn)行部署。整個(gè)產(chǎn)品的版本由應(yīng)用系統(tǒng)管理到里面的每個(gè)組件，這些都將是發(fā)生變化的點(diǎn)。

業(yè)務(wù)架構(gòu)設(shè)計(jì)

業(yè)務(wù)架構(gòu)設(shè)計(jì)是定義和識(shí)別業(yè)務(wù)組件的基礎(chǔ)。對(duì)于業(yè)務(wù)架構(gòu)的設(shè)計(jì)需要遵循企業(yè)架構(gòu)方法論中業(yè)務(wù)流程分析思路，借鑒IBM的CBM組件化的業(yè)務(wù)模型建模思路。

業(yè)務(wù)架構(gòu)是一個(gè)純粹意義上的業(yè)務(wù)概念，只關(guān)心具體的業(yè)務(wù)域和業(yè)務(wù)功能。業(yè)務(wù)架構(gòu)可以看做由多個(gè)高內(nèi)聚、低耦合的業(yè)務(wù)組件構(gòu)成，因此在業(yè)務(wù)架構(gòu)完成后基本就確定了業(yè)務(wù)組件的劃分方法和粒度等問(wèn)題。

業(yè)務(wù)組件的劃分需要和業(yè)務(wù)架構(gòu)圖對(duì)應(yīng)，可以將業(yè)務(wù)架構(gòu)圖中的每個(gè)業(yè)務(wù)模塊識(shí)別和定義為一個(gè)業(yè)務(wù)組件，也可以根據(jù)高內(nèi)聚、低耦合準(zhǔn)則將多個(gè)業(yè)務(wù)模塊合并為一個(gè)業(yè)務(wù)組件。以采購(gòu)管理業(yè)務(wù)域?yàn)槔?，?jīng)過(guò)前期的流程分析和業(yè)務(wù)交互矩陣分析，得出如下的業(yè)務(wù)架構(gòu)圖：

進(jìn)一步基于業(yè)務(wù)高內(nèi)聚的思想，可以將采購(gòu)管理業(yè)務(wù)劃分為招投標(biāo)管理、采購(gòu)管理、基礎(chǔ)數(shù)據(jù)管理、采購(gòu)績(jī)效分析等多個(gè)業(yè)務(wù)組件并指導(dǎo)后續(xù)的組件設(shè)計(jì)和開(kāi)發(fā)。

比如我們基于價(jià)值鏈已經(jīng)看到供應(yīng)鏈跨越流程，那么我們可以對(duì)供應(yīng)鏈流程進(jìn)行梳理。

梳理完后你會(huì)發(fā)現(xiàn)，輸出的職能帶流程圖中的大階段剛好就是你業(yè)務(wù)架構(gòu)里面的業(yè)務(wù)域或業(yè)務(wù)單元?；蛘吡鞒虉D中的業(yè)務(wù)活動(dòng)剛好就是你業(yè)務(wù)架構(gòu)分解到最底層的業(yè)務(wù)功能模塊。

即當(dāng)我們流程分析到最底層后，我們就可以抽象輸出一個(gè)最底層的業(yè)務(wù)架構(gòu)圖。比如對(duì)應(yīng)供應(yīng)鏈和采購(gòu)管理，我們可以輸出到最底層的業(yè)務(wù)架構(gòu)圖或業(yè)務(wù)組件圖。

邏輯架構(gòu)設(shè)計(jì)

對(duì)于應(yīng)用層的邏輯架構(gòu)仍然參考平臺(tái)+服務(wù)+應(yīng)用分層的思路，對(duì)于新平臺(tái)架構(gòu)下應(yīng)用必須結(jié)合平臺(tái)層和服務(wù)能力才能組裝成為一個(gè)傳統(tǒng)的完整應(yīng)用。對(duì)于應(yīng)用層而言，其中仍然分為數(shù)據(jù)層、業(yè)務(wù)邏輯層和展現(xiàn)層的三層架構(gòu)模式：

數(shù)據(jù)層

數(shù)據(jù)層主要包括了對(duì)于主數(shù)據(jù)等共享數(shù)據(jù)的訪問(wèn)和讀取，也包括了對(duì)業(yè)務(wù)組件模塊自己私有數(shù)據(jù)的CRUD操作。數(shù)據(jù)層可以直接調(diào)用DaaS服務(wù)層能力操作底層數(shù)據(jù)庫(kù)，也可以直接調(diào)用封裝后的領(lǐng)域數(shù)據(jù)服務(wù)能力查詢(xún)和訪問(wèn)數(shù)據(jù)。

業(yè)務(wù)邏輯層

業(yè)務(wù)邏輯層和傳統(tǒng)業(yè)務(wù)邏輯層最大的區(qū)別是體現(xiàn)了SOA服務(wù)化的思想。即對(duì)于業(yè)務(wù)流程和功能的業(yè)務(wù)實(shí)現(xiàn)是通過(guò)平臺(tái)層提供的技術(shù)服務(wù)和業(yè)務(wù)服務(wù)能力進(jìn)行組合和組裝實(shí)現(xiàn)的。這既可以通過(guò)傳統(tǒng)的代碼開(kāi)發(fā)和服務(wù)調(diào)用來(lái)實(shí)現(xiàn)，也可以通過(guò)類(lèi)似BPEL設(shè)計(jì)和建模工具等可視化的進(jìn)行靈活配置和實(shí)現(xiàn)。

前端展現(xiàn)層

展現(xiàn)層主要是各種前端和界面實(shí)現(xiàn)技術(shù)，包括了JSP，HTML和現(xiàn)在主流的VUE, React框架等。展現(xiàn)層通過(guò)調(diào)用邏輯層的服務(wù)能力進(jìn)行數(shù)據(jù)的存取和業(yè)務(wù)規(guī)則的實(shí)現(xiàn)，同時(shí)也包括了界面集成技術(shù)實(shí)現(xiàn)多個(gè)業(yè)務(wù)組件的界面集成。

技術(shù)架構(gòu)設(shè)計(jì)

對(duì)于應(yīng)用技術(shù)架構(gòu)設(shè)計(jì)，主要還是參考傳統(tǒng)的分層架構(gòu)模式，結(jié)合SOA和組件化思想進(jìn)行調(diào)整，其中重點(diǎn)是業(yè)務(wù)邏輯層和Web層兩方面的內(nèi)容的細(xì)化：

業(yè)務(wù)邏輯層

業(yè)務(wù)邏輯層本質(zhì)是提供業(yè)務(wù)服務(wù)能力的服務(wù)組件層，其中包括了數(shù)據(jù)訪問(wèn)層，內(nèi)部的技術(shù)組件，內(nèi)部的服務(wù)接入軟總線，外部的服務(wù)代理實(shí)現(xiàn)服務(wù)接入和服務(wù)發(fā)布。業(yè)務(wù)邏輯層最終的業(yè)務(wù)能力將以?xún)?nèi)部軟總線的方式提供給Web層使用。

Web容器層和界面展現(xiàn)

該層的重點(diǎn)是實(shí)現(xiàn)標(biāo)準(zhǔn)的MVC模式。對(duì)于來(lái)自前端界面應(yīng)用的請(qǐng)求信息先經(jīng)過(guò)控制器處理后轉(zhuǎn)給模型處理再進(jìn)行視圖層面輸出，以實(shí)現(xiàn)界面顯示和數(shù)據(jù)處理的分離。如通過(guò)Java的Struts框架來(lái)實(shí)現(xiàn)標(biāo)準(zhǔn)的MVC模式等。

集成架構(gòu)設(shè)計(jì)

業(yè)務(wù)組件以 Web 服務(wù)的方式提供接口，通過(guò)企業(yè)服務(wù)總線連接。業(yè)務(wù)組件內(nèi)部為了實(shí)現(xiàn)高可復(fù)用性和高效性，采用基于 OSGi 內(nèi)部軟總線標(biāo)準(zhǔn)進(jìn)行構(gòu)建模塊，實(shí)現(xiàn)內(nèi)部模塊之間的松耦合。即在業(yè)務(wù)組件內(nèi)部基于 OSGi 標(biāo)準(zhǔn)進(jìn)行模塊化設(shè)計(jì)，將業(yè)務(wù)組件進(jìn)一步分解為松耦合的模塊（Bundle），使得業(yè)務(wù)組件本身更加靈活。

基于 OSGi 標(biāo)準(zhǔn)，業(yè)務(wù)組件內(nèi)部的模塊通過(guò)一個(gè)具有動(dòng)態(tài)加載類(lèi)功能的微內(nèi)核連接，統(tǒng)一管理各個(gè)模塊。為了便于管理，將不同模塊之間的類(lèi)接口采用服務(wù)注冊(cè)的方式進(jìn)行管理，具有類(lèi)動(dòng)態(tài)加載功能的微內(nèi)核和類(lèi)接口管理組成類(lèi)總線（JCB）的基本功能；為了更好的實(shí)現(xiàn)重用，有些模塊是共用的，比如數(shù)據(jù)訪問(wèn)模塊、日志管理模塊等。

服務(wù)軟總線

實(shí)現(xiàn)一個(gè)業(yè)務(wù)組件內(nèi)部的服務(wù)注冊(cè)、調(diào)用和服務(wù)管理，一般采用比較輕量的如OSGi標(biāo)準(zhǔn)來(lái)實(shí)現(xiàn)。軟總線機(jī)制可以保證業(yè)務(wù)組件內(nèi)部的進(jìn)一步松耦合設(shè)計(jì)。

注：在當(dāng)前微服務(wù)架構(gòu)下，我們看到實(shí)際上組件之間的接口集成，已經(jīng)不再需要類(lèi)似OSGI這種內(nèi)部軟總線，而是直接采用去中心化的服務(wù)注冊(cè)中心來(lái)完成集成工作。

服務(wù)組件和技術(shù)組件

服務(wù)組件是業(yè)務(wù)組件中唯一和外部進(jìn)行交互的接口組件，包括了服務(wù)消費(fèi)和服務(wù)調(diào)用均在服務(wù)組件完成。技術(shù)組件為服務(wù)組件的具體實(shí)現(xiàn)，內(nèi)部功能的業(yè)務(wù)規(guī)則實(shí)現(xiàn)等。

服務(wù)代理

服務(wù)代理包括了服務(wù)消費(fèi)代理和服務(wù)發(fā)布代理。業(yè)務(wù)組件本身要消費(fèi)外部的服務(wù)，包括技術(shù)服務(wù)、流程服務(wù)和其它業(yè)務(wù)組件提供的業(yè)務(wù)服務(wù)，這些通過(guò)服務(wù)消費(fèi)代理來(lái)完成。同時(shí)業(yè)務(wù)組件本身也需要向外部其它業(yè)務(wù)組件提供可復(fù)用的業(yè)務(wù)服務(wù)能力，因此需要將內(nèi)部的服務(wù)接口進(jìn)一步通過(guò)服務(wù)發(fā)布代理，發(fā)布為外部可訪問(wèn)的業(yè)務(wù)服務(wù)并注冊(cè)到外部ESB服務(wù)總線上。

組件間整體框架集成

業(yè)務(wù)組件本身就是一個(gè)能夠提供獨(dú)立業(yè)務(wù)價(jià)值能力的小應(yīng)用系統(tǒng)。組件的集成包括了組件的縱向集成和橫向集成。組件的縱向集成即和PaaS平臺(tái)技術(shù)服務(wù)能力的集成，通過(guò)集成后形成一個(gè)完整的應(yīng)用。橫向集成則是流程驅(qū)動(dòng)的業(yè)務(wù)組件之間通過(guò)業(yè)務(wù)服務(wù)的橫向協(xié)同和集成，通過(guò)橫向集成加上和外層應(yīng)用框架和門(mén)戶(hù)的集成后，多個(gè)業(yè)務(wù)組件將構(gòu)成傳統(tǒng)的完整業(yè)務(wù)系統(tǒng)。

應(yīng)用框架集成

在企業(yè)私有云PaaS平臺(tái)的建設(shè)過(guò)程中，雖然基于平臺(tái)+應(yīng)用和SOA組件化架構(gòu)思想真正實(shí)現(xiàn)了高復(fù)用和對(duì)業(yè)務(wù)的靈活應(yīng)變能力，但是一個(gè)傳統(tǒng)完整的業(yè)務(wù)系統(tǒng)已經(jīng)被分解到了平臺(tái)，服務(wù)和應(yīng)用多個(gè)層面的技術(shù)組件，業(yè)務(wù)組件和服務(wù)中。因此這些分散的組件如何最終集成和還原為一個(gè)傳統(tǒng)意義上完整的業(yè)務(wù)系統(tǒng)將成為應(yīng)用集成必須考慮的重點(diǎn)內(nèi)容。

結(jié)合實(shí)踐經(jīng)驗(yàn)，最好方式是通過(guò)門(mén)戶(hù)+外層應(yīng)用框架來(lái)實(shí)現(xiàn)總體的集成，具體參考：

以上圖為例來(lái)看一個(gè)完整的業(yè)務(wù)系統(tǒng)。除了白色部分外，其余的組成部分都應(yīng)該是有平臺(tái)層統(tǒng)一規(guī)劃建設(shè)和提供。應(yīng)用外層框架和組件動(dòng)態(tài)裝載是重新還原一個(gè)傳統(tǒng)意義上的業(yè)務(wù)系統(tǒng)的集成。應(yīng)用外層框架首先是需要和門(mén)戶(hù)進(jìn)行集成，實(shí)現(xiàn)基本的統(tǒng)一認(rèn)證和單點(diǎn)登錄；其次是讀取系統(tǒng)管理的基本參數(shù)和配置信息，實(shí)現(xiàn)外層界面和菜單資源等的裝載和初始化；最后是根據(jù)應(yīng)用配置文件靈活的對(duì)PaaS平臺(tái)層的技術(shù)組件（系統(tǒng)管理，流程引擎），應(yīng)用層的業(yè)務(wù)組件進(jìn)行動(dòng)態(tài)裝載。

應(yīng)用外層UI界面框架需要基于可重用，可配置的思想獨(dú)立開(kāi)發(fā)，該框架是一個(gè)包括了菜單描述文件，頁(yè)面描述文件，工具欄描述文件，頁(yè)面布局描述文件組成一個(gè)基本的頁(yè)面框架，具體說(shuō)明如下。

后臺(tái)回復(fù)?學(xué)習(xí)資料?領(lǐng)取學(xué)習(xí)視頻

如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝