一、什么是基礎(chǔ)平臺(tái)

基礎(chǔ)平臺(tái)對(duì)應(yīng)于業(yè)務(wù)應(yīng)用，主要處理技術(shù)問(wèn)題，是為業(yè)務(wù)應(yīng)用提供技術(shù)支撐以及技術(shù)方案的模塊或者組件。其目的是使得應(yīng)用組件可只關(guān)注于業(yè)務(wù)邏輯，而不考慮或者少考慮技術(shù)問(wèn)題。

基礎(chǔ)平臺(tái)通常包括如下：基礎(chǔ)功能，開(kāi)發(fā)類(lèi)庫(kù)，開(kāi)發(fā)模式以及開(kāi)發(fā)部署工具。

二、為何要基礎(chǔ)平臺(tái)

應(yīng)用系統(tǒng)的設(shè)計(jì)可以說(shuō)是將一個(gè)業(yè)務(wù)語(yǔ)言翻譯成程序語(yǔ)言的過(guò)程，這個(gè)過(guò)程同時(shí)處理兩個(gè)內(nèi)容：業(yè)務(wù)和技術(shù)。

1. 學(xué)習(xí)業(yè)務(wù)，編寫(xiě)的代碼符合用例的流程；

2. 學(xué)習(xí)技術(shù)，編寫(xiě)的代碼符合技術(shù)平臺(tái)的規(guī)范和要求。

這里不同底層技術(shù)的難易度不同，導(dǎo)致學(xué)習(xí)成本、開(kāi)發(fā)成本和應(yīng)用成本也不同。同時(shí)對(duì)于一個(gè)有較長(zhǎng)生命周期的軟件項(xiàng)目或者產(chǎn)品，其依賴(lài)的底層技術(shù)的升級(jí)也會(huì)帶來(lái)相應(yīng)的維護(hù)成不

面對(duì)特定領(lǐng)域的軟件項(xiàng)目或者產(chǎn)品，其所依賴(lài)的底層技術(shù)的廣度和深度相對(duì)穩(wěn)定，基礎(chǔ)平臺(tái)可以填平或者減少技術(shù)層面的鴻溝。

那么，我們就面臨另一個(gè)問(wèn)題，即：業(yè)界已經(jīng)存在大量?jī)?yōu)秀的開(kāi)源框架，我們?yōu)楹我A(chǔ)平臺(tái)。

首先，大量?jī)?yōu)秀開(kāi)源框架可以幫助我們，但是：

1.優(yōu)秀的開(kāi)源框架通常偏向通用性，而面向特定領(lǐng)域的相關(guān)特性和功能還不支持；即便有面向特定領(lǐng)域的，其支持的特性還存在一定差異性；同時(shí)其未必支持相應(yīng)的基礎(chǔ)設(shè)施。

因此需要進(jìn)行二次開(kāi)發(fā)，以完善所需的基礎(chǔ)設(shè)施；

2.優(yōu)秀的開(kāi)源框架在通用性支持廣泛，提供多種選擇，同時(shí)還有一定學(xué)習(xí)成本；而面向特定領(lǐng)域，需要的模式相對(duì)固定。

因此需要進(jìn)行定制，減少學(xué)習(xí)成本，提供開(kāi)發(fā)模式，進(jìn)而提高開(kāi)發(fā)效率；

3.技術(shù)升級(jí)的平穩(wěn)性，雖然優(yōu)秀的開(kāi)源框架會(huì)盡量提供升級(jí)平穩(wěn)性，但是和產(chǎn)品目標(biāo)未必一致；也需要進(jìn)一步的測(cè)試工作；為了進(jìn)一步減少成本和風(fēng)險(xiǎn)需要基礎(chǔ)平臺(tái)來(lái)處理相應(yīng)工作；

4.開(kāi)源框架本身存在一定的缺陷，其修復(fù)有一定周期，和產(chǎn)品項(xiàng)目周期不同步。所以也需要做些修復(fù)和規(guī)避工作；

因此開(kāi)發(fā)維護(hù)支持特定領(lǐng)域的基礎(chǔ)平臺(tái)存在客觀需要。更進(jìn)一步，基礎(chǔ)平臺(tái)是在關(guān)注點(diǎn)分離原則下的一個(gè)必然產(chǎn)物。

三、基礎(chǔ)平臺(tái)的考核

基礎(chǔ)平臺(tái)的考核需要依照其目標(biāo)以及特性來(lái)，包括：

1. 功能復(fù)用所帶來(lái)的成本降低。這個(gè)比較好衡量，直接使用復(fù)用。

2. 提高業(yè)務(wù)應(yīng)用的開(kāi)發(fā)效率（新增或維護(hù)）。這個(gè)指標(biāo)的衡量有一定難度，需要有兩個(gè)近似項(xiàng)目分別應(yīng)用不同基礎(chǔ)平臺(tái)，并在一個(gè)較長(zhǎng)時(shí)期內(nèi)（比如2年，以便消除人員差異、具體功能差異性和難易度）。

3. 技術(shù)風(fēng)險(xiǎn)的可控性，技術(shù)更新的平穩(wěn)性。這個(gè)指標(biāo)比較好衡量，需要收集開(kāi)發(fā)過(guò)程中處理各種突發(fā)技術(shù)問(wèn)題以及其解決成本。

4. 招聘成本。這個(gè)指標(biāo)也屬于比較好衡量的。

5. 架構(gòu)推廣。架構(gòu)推廣有賴(lài)于一個(gè)良好的基礎(chǔ)平臺(tái)，避免成為空中樓閣。

總之，基礎(chǔ)平臺(tái)的應(yīng)用將使開(kāi)發(fā)和維護(hù)的成本具備平穩(wěn)性和收斂性。

四、基礎(chǔ)設(shè)施的選型

應(yīng)考慮幾點(diǎn)：1. 商業(yè)角度的維護(hù)性和升級(jí)性；2. 組織的學(xué)習(xí)和管理能力；3. 基礎(chǔ)設(shè)施自身功能以及所支持的開(kāi)發(fā)效率.以下是詳細(xì)要求：

五、基礎(chǔ)平臺(tái)的構(gòu)建

選取基礎(chǔ)設(shè)施之后就根據(jù)需要進(jìn)行二次開(kāi)發(fā)。包括如下內(nèi)容：

1. 平臺(tái)的核心

1.1 領(lǐng)域化支持

領(lǐng)域化的核心是建立業(yè)務(wù)相關(guān)的領(lǐng)域模型以及領(lǐng)域服務(wù)。

領(lǐng)域化支持需要三個(gè)方面：

A. 持久層支持：這個(gè)是領(lǐng)域化支持第一個(gè)要素，持久層能夠持久化并重建領(lǐng)域模型。

從持久化的方式來(lái)看可以分為文件形式和數(shù)據(jù)庫(kù)形式，以及二進(jìn)制形式或文本形式。由于數(shù)據(jù)庫(kù)的廣泛使用，ORM是常見(jiàn)的方式；但有時(shí)這不夠，我們可能還在此基礎(chǔ)上，進(jìn)一步擴(kuò)展提供二進(jìn)制或文本形式的持久化策略。

B. 業(yè)務(wù)邏輯支持：包括兩個(gè)方面：a. 領(lǐng)域模型涉及到的業(yè)務(wù)邏輯依賴(lài)；b.領(lǐng)域模型的并發(fā)支持；c. 領(lǐng)域服務(wù)的構(gòu)建；

C. 界面層支持：包括延遲加載以及長(zhǎng)會(huì)話(huà)支持；

領(lǐng)域模型雖然包括所有的數(shù)據(jù)，但考慮到性能，以及特定界面層所需要的數(shù)據(jù)通常是子集，因而界面層延遲加載異常重要。而領(lǐng)域模型跨界面?zhèn)鬟f，即長(zhǎng)會(huì)話(huà)操作，也成為一種必然。

1.2 組件化支持

在組件化技術(shù)上，業(yè)界現(xiàn)有的規(guī)范和開(kāi)源實(shí)現(xiàn)，尤其OSGi和SCA都提出了各自的組件規(guī)范，并且OSGi和SCA有融合方案。但是總體上看，由于其關(guān)注的組件元素是最為經(jīng)典的，在實(shí)踐應(yīng)用上還需要有一定擴(kuò)展。

基礎(chǔ)平臺(tái)需要提供一個(gè)簡(jiǎn)易的組件支持框架，可以支持掃描，識(shí)別并加載組件下的各種技術(shù)類(lèi)型資源。包括：界面擴(kuò)展點(diǎn)，國(guó)際化消息文件，應(yīng)用服務(wù)，監(jiān)聽(tīng)服務(wù)，領(lǐng)域模型，配置數(shù)據(jù)（包括初始數(shù)據(jù)和運(yùn)行數(shù)據(jù)），以及數(shù)據(jù)庫(kù)表；

主要包括如下功能：

0. 組件的加載和運(yùn)行（依賴(lài)檢查）；

分為兩個(gè)層次：部署期，即部署幾個(gè)組件就加載幾個(gè)組件；運(yùn)行期，根據(jù)運(yùn)行期信息，加載和運(yùn)行組件。部署期組件體系相對(duì)于運(yùn)行期較為簡(jiǎn)單，實(shí)際上部署期可以完全不考慮組件的邊界，而直接加載組件內(nèi)的不同技術(shù)工件；而運(yùn)行期需要嚴(yán)格明確組件的邊界。

1. 組件間集成和交互方法：同步異步，進(jìn)程內(nèi)或分布式），包括UI，服務(wù)，對(duì)象和數(shù)據(jù)庫(kù)；

2. 組件間集成和交互的上下文數(shù)據(jù)傳遞，如權(quán)限和事務(wù)等待；

3. 組件的安裝、卸載、升級(jí)和定制；

1.3 產(chǎn)品化支持

    產(chǎn)品化支持包括了兩個(gè)方面：

    參數(shù)化支持：用戶(hù)可以通過(guò)修改預(yù)定義的參數(shù)設(shè)定調(diào)整系統(tǒng)行為。

    定制化支持：包括兩個(gè)層面：1.用戶(hù)定制化，即用戶(hù)通過(guò)系統(tǒng)提供的工具進(jìn)行的定制化；2.系統(tǒng)定制化，即通過(guò)開(kāi)發(fā)人員進(jìn)行編碼開(kāi)發(fā)提供的定制化。

1.4 平臺(tái)化支持

       框架提供相應(yīng)的事務(wù)管理，集成支持和并發(fā)處理等等涉及各個(gè)技術(shù)支持，使得業(yè)務(wù)應(yīng)用僅需關(guān)注業(yè)務(wù)邏輯。

2. 平臺(tái)的功能支持

0. 業(yè)務(wù)事務(wù)與日志

這里提的業(yè)務(wù)事務(wù)，是不同于數(shù)據(jù)庫(kù)所提供的物理事務(wù)。以B/S應(yīng)用為例，一個(gè)業(yè)務(wù)事務(wù)，對(duì)應(yīng)如下：

a. 一個(gè)業(yè)務(wù)事務(wù)：一個(gè)web請(qǐng)求，一個(gè)服務(wù)調(diào)用，一筆數(shù)據(jù)更新；

b. 一個(gè)業(yè)務(wù)事務(wù)：一個(gè)web請(qǐng)求，多個(gè)服務(wù)調(diào)用，多筆數(shù)據(jù)更新；

c. 一個(gè)業(yè)務(wù)事務(wù)：多個(gè)web請(qǐng)求，n個(gè)服務(wù)調(diào)用，多筆數(shù)據(jù)更新；

對(duì)于a，業(yè)務(wù)事務(wù)和物理事務(wù)的邊界是一致的；而對(duì)于b和c，顯然，由于物理事務(wù)和業(yè)務(wù)事務(wù)邊界的不一致性，導(dǎo)致基于傳統(tǒng)的物理事務(wù)是無(wú)法跟蹤一個(gè)業(yè)務(wù)事務(wù)所帶來(lái)的數(shù)據(jù)變更。

為了可以跟蹤業(yè)務(wù)事務(wù)，就需要通過(guò)建立業(yè)務(wù)事務(wù)及其業(yè)務(wù)日志來(lái)記錄并跟蹤數(shù)據(jù)的變化。取決于業(yè)務(wù)應(yīng)用，更多的時(shí)候，只需要跟蹤相應(yīng)歷史數(shù)據(jù)即可。

此外，若需要提供分布式事務(wù)（不依賴(lài)特定的商業(yè)產(chǎn)品），也需要業(yè)務(wù)事務(wù)和日志的支持。

1. 系統(tǒng)操作日志

系統(tǒng)操作日志通常是審計(jì)相關(guān)的。在嚴(yán)格的審計(jì)要求下，業(yè)務(wù)日志可以提供完整的數(shù)據(jù)跟蹤能力。操作日志相對(duì)于業(yè)務(wù)日志，較為簡(jiǎn)單，只需要跟蹤相應(yīng)的歷史數(shù)據(jù)。

2. 安全體系

現(xiàn)有基礎(chǔ)設(shè)施大都提供了豐富了安全體系。不過(guò)開(kāi)源框架尚未提供一種基于數(shù)據(jù)庫(kù)，可以由最終用戶(hù)配置的安全體系。

基礎(chǔ)平臺(tái)需要在如下方面加以完善：

a.    開(kāi)放角色定義；

b.   開(kāi)放角色可訪(fǎng)問(wèn)資源定義；

c.    開(kāi)放角色可訪(fǎng)問(wèn)數(shù)據(jù)定義；

實(shí)際上，b和c是a的基礎(chǔ)，只有角色的資源和數(shù)據(jù)可以定義，角色定義才有意義。

此外，對(duì)于可訪(fǎng)問(wèn)數(shù)據(jù)定義，還存在一定爭(zhēng)議，認(rèn)為此是業(yè)務(wù)范疇，基礎(chǔ)平臺(tái)或框架不做處理。若要在基礎(chǔ)平臺(tái)提供支持，可以有兩種策略：在業(yè)務(wù)層檢查和在數(shù)據(jù)連接層增強(qiáng)。業(yè)務(wù)層的檢查通常通過(guò)AOP技術(shù)進(jìn)行，此種方法存在一定的性能消耗問(wèn)題，且其適應(yīng)性存在局限；而數(shù)據(jù)連接層，則是針對(duì)最終的sql語(yǔ)句進(jìn)行解析和增強(qiáng)，由于SQL是標(biāo)準(zhǔn)，其適應(yīng)性更強(qiáng)些。

3. 批處理服務(wù)

批處理或者說(shuō)batch處理。

支持不同的觸發(fā)策略：定時(shí)以及手動(dòng)策略；支持批處理的多步驟處理，包括步驟同一數(shù)據(jù)、不同步驟不同數(shù)據(jù)，后一步驟處理前一步驟成功的數(shù)據(jù)；提供不同的控制策略：包括中斷以及暫停；支持不同的批處理策略：串行和并發(fā)；支持不同的事務(wù)控制策略；完善的運(yùn)行日志支持；支持不同的運(yùn)行策略：?jiǎn)螜C(jī)和集群；

4. 打印和報(bào)表

對(duì)于信息系統(tǒng)來(lái)說(shuō)，打印和報(bào)表這兩塊幾乎是少不了的。

一方面是打印和報(bào)表通常都需要通過(guò)第三方支持來(lái)加以實(shí)現(xiàn)，一定的開(kāi)發(fā)模式有助于降低學(xué)習(xí)成本并提高開(kāi)發(fā)效率；另一方面是針對(duì)不同應(yīng)用領(lǐng)域，打印和報(bào)表本身存在一定管理需求。

5．系統(tǒng)診斷支持

3. 平臺(tái)的開(kāi)發(fā)模式

0. 國(guó)際化支持

通常提到國(guó)際化，最能想到的時(shí)文本消息的國(guó)際化。文本消息的國(guó)際化固然很重要，但是國(guó)際化不僅僅包括文本消息。

1.文字消息國(guó)際化

對(duì)于異步操作或者分布式操作，以及操作日志而言，文本消息并非直接呈現(xiàn)，而是存儲(chǔ)于數(shù)據(jù)庫(kù)或者文件，并在用戶(hù)查詢(xún)時(shí)呈現(xiàn)。此時(shí)若存儲(chǔ)的是國(guó)際化后的文本消息，則有局限性：文本消息在產(chǎn)生時(shí)決定，而非查看時(shí)決定，它的假定是系統(tǒng)的所有用戶(hù)都是同一個(gè)Locale；但是對(duì)于擁有多locale用戶(hù)的系統(tǒng)，因此支持文本消息存儲(chǔ)信息為非國(guó)際化后結(jié)果，而在查詢(xún)時(shí)根據(jù)用戶(hù)的區(qū)域轉(zhuǎn)換為合適的國(guó)際化文本消息；

2.布局國(guó)際化

多數(shù)的布局方式是從上而下，從左而右。尤其是界面上的表格布局，通常都是label在左，而輸入輸出控件在右。這樣的布局方式在大部分國(guó)家和人群是沒(méi)有問(wèn)題的。然而還有另外：阿拉伯國(guó)家是從右到左。而中立的做法是label在上，而輸入輸出控件在下，形成上下布局。這樣的布局方式是更為通用。

若要支持兩者布局方式的自由轉(zhuǎn)換，在界面不能采用傳統(tǒng)的表格布局。同時(shí)，label和輸入輸出控件必需是一個(gè)邏輯控件。現(xiàn)有的大量的控件設(shè)計(jì)都不是如此，label是獨(dú)立的。因此也封裝新的表格控件；

3.業(yè)務(wù)時(shí)間

大部分情況下，一個(gè)國(guó)家通常只有一個(gè)時(shí)區(qū)，而像美國(guó)，俄羅斯這樣跨多個(gè)時(shí)區(qū)的國(guó)家相對(duì)較少。若一個(gè)業(yè)務(wù)系統(tǒng)的用戶(hù)跨越了多個(gè)時(shí)區(qū)。系統(tǒng)就面臨業(yè)務(wù)時(shí)間的處理。即用戶(hù)的時(shí)區(qū)和系統(tǒng)所在時(shí)區(qū)不同。

系統(tǒng)處理業(yè)務(wù)時(shí)必需同時(shí)記錄兩個(gè)時(shí)間，一是用戶(hù)所在時(shí)區(qū)時(shí)間，一個(gè)是系統(tǒng)時(shí)間。而業(yè)務(wù)程序在處理數(shù)據(jù)時(shí)，必需指明當(dāng)前采用的時(shí)間類(lèi)型。

此外，數(shù)據(jù)庫(kù)層面還需要考慮，并非所有數(shù)據(jù)庫(kù)支持記錄時(shí)區(qū)。

4.計(jì)量單位，多幣種；

國(guó)際化面臨的另一個(gè)問(wèn)題就是度量衡問(wèn)題，常見(jiàn)的有英制，美制。用戶(hù)自行轉(zhuǎn)換制式會(huì)帶來(lái)使用上不便。由基礎(chǔ)平臺(tái)提供封裝并自動(dòng)轉(zhuǎn)換能力。

另一個(gè)更為重要的問(wèn)題時(shí)多幣種問(wèn)題。通常發(fā)生的交易系統(tǒng)上，交易貨幣和本位幣的不同。系統(tǒng)必須同時(shí)記錄兩個(gè)幣種，以幫助統(tǒng)計(jì)匯兌損失。

1. 異常體系

異常體系的設(shè)計(jì)

A.異常體系原則

異常屬于程序接口的一部分，是除返回值以外的一類(lèi)輸出對(duì)象。Java語(yǔ)言中異常分為checked和Unchecked兩種，而.NET只有一種Unchecked異常。

B.異常的應(yīng)用：

異常用于提示（人工處理）或者用于驅(qū)動(dòng)流程。實(shí)踐中，由于兩點(diǎn)原因使得異常通常用于提示（人工處理）而非驅(qū)動(dòng)流程。

B.1.由于異常屬于正常流程體系外的輸出，屬于不受歡迎的輸出。通常系統(tǒng)上出現(xiàn)異常后，程序也無(wú)法做相應(yīng)的處理。

B.2.異常在捕獲體系上自身的缺陷。OO設(shè)計(jì)講究是是抽象和封裝，而異常捕獲體系是順序捕獲，捕獲程序必須了解異常的繼承體系，否則一定高層異常早于底層異常則將導(dǎo)致底層異常無(wú)法被捕獲并處理。

C.異常的分類(lèi)

異常分為校驗(yàn)錯(cuò)誤，業(yè)務(wù)告警，業(yè)務(wù)異常和框架異常

C.1.校驗(yàn)錯(cuò)誤通常是一種輕量的業(yè)務(wù)異常，校驗(yàn)錯(cuò)誤所依賴(lài)信息單一或較少。

C.2.業(yè)務(wù)異常通常為用戶(hù)業(yè)務(wù)數(shù)據(jù)錯(cuò)誤導(dǎo)致的異常信息，通常依賴(lài)較多的數(shù)據(jù)和邏輯。因此針對(duì)此類(lèi)異常只要以友好的方式展示在UI上，用戶(hù)通過(guò)修正輸入等方式解決。

C.3.框架異常則是基礎(chǔ)平臺(tái)自身錯(cuò)誤，用戶(hù)無(wú)法通過(guò)界面操作加以解決，需要開(kāi)發(fā)人員介入修正。

2. 多任務(wù)處理

多任務(wù)處理包括了異步操作和并發(fā)處理兩部分內(nèi)容。多任務(wù)處理在技術(shù)上屬于一個(gè)較難的部分，開(kāi)發(fā)以及測(cè)試的成本都比較高。

第一個(gè)要處理的就是異常的捕獲以及重拋出。

其次是并發(fā)處理。包括兩個(gè)部分：并發(fā)策略（鎖）控制以及并發(fā)操作支持。

并發(fā)策略（鎖）不僅僅是基礎(chǔ)平臺(tái)提供相應(yīng)框架支持，還是涉及到應(yīng)用系統(tǒng)的設(shè)計(jì)包括模型及其服務(wù)。這點(diǎn)上目前沒(méi)有通用的并發(fā)框架，只能是根據(jù)特定應(yīng)用領(lǐng)域，制定相應(yīng)的支持。

并發(fā)操作支持，系統(tǒng)提供元數(shù)據(jù)，自動(dòng)分解輸入?yún)?shù)集合，進(jìn)行并發(fā)處理（可參考Terrecota）。

3. 應(yīng)用交互模式

基礎(chǔ)平臺(tái)提供基類(lèi)，同時(shí)支持一些約定，封裝常用的開(kāi)發(fā)模式，如CRUD，以及異步控制等等面向特定交互應(yīng)用的開(kāi)發(fā)模式。

4. 平臺(tái)的類(lèi)庫(kù)

0. 工具類(lèi)

包括類(lèi)操作，對(duì)象操作，斷言操作，容器操作等。

1. UI控件

雖然基礎(chǔ)設(shè)施以及開(kāi)源界提供豐富的UI控件。但是還是存在一些不足。

第一是UI控件適配性不足，應(yīng)用系統(tǒng)已經(jīng)提供各個(gè)模型以及服務(wù)，但依然需要寫(xiě)代碼，而非配置方式；需要基礎(chǔ)平臺(tái)對(duì)已有控件擴(kuò)展，提供適配能力，使得應(yīng)用組件通過(guò)配置將數(shù)據(jù)暴露給UI控件，從而使得應(yīng)用組件關(guān)注于業(yè)務(wù)邏輯。

第二是UI控件的國(guó)際化支持，詳見(jiàn)3.0國(guó)際化支持。

第三是UI控件在不同模式下的展示，比如在編輯模式和只讀模式下的展示。

2. 文件操作支持

3. 網(wǎng)絡(luò)通訊支持

包括底層網(wǎng)絡(luò)通訊（底層網(wǎng)絡(luò)協(xié)議）支持，以及上層網(wǎng)絡(luò)通訊（應(yīng)用網(wǎng)絡(luò)協(xié)議，如Web Sevice，RMI等）。

4. 參數(shù)化支持

5. 平臺(tái)的工具

1. 打包工具

2. 部署工具

3. 設(shè)計(jì)工具

4. 生成工具

無(wú)論何種工具都是幫助提高工作效率。即它不解決業(yè)務(wù)和技術(shù)的核心問(wèn)題（核心問(wèn)題的解決依賴(lài)于整體設(shè)計(jì)方案），而是提供一個(gè)加速器，處理所謂的臟活累活。