一、什么是基礎平臺

基礎平臺對應于業務應用，主要處理技術問題，是為業務應用提供技術支撐以及技術方案的模塊或者組件。其目的是使得應用組件可只關注于業務邏輯，而不考慮或者少考慮技術問題。

基礎平臺通常包括如下：基礎功能，開發類庫，開發模式以及開發部署工具。

二、為何要基礎平臺

應用系統的設計可以說是將一個業務語言翻譯成程序語言的過程，這個過程同時處理兩個內容：業務和技術。

1. 學習業務，編寫的代碼符合用例的流程；

2. 學習技術，編寫的代碼符合技術平臺的規范和要求。

這里不同底層技術的難易度不同，導致學習成本、開發成本和應用成本也不同。同時對于一個有較長生命周期的軟件項目或者產品，其依賴的底層技術的升級也會帶來相應的維護成不

面對特定領域的軟件項目或者產品，其所依賴的底層技術的廣度和深度相對穩定，基礎平臺可以填平或者減少技術層面的鴻溝。

那么，我們就面臨另一個問題，即：業界已經存在大量優秀的開源框架，我們為何要基礎平臺。

首先，大量優秀開源框架可以幫助我們，但是：

1.優秀的開源框架通常偏向通用性，而面向特定領域的相關特性和功能還不支持；即便有面向特定領域的，其支持的特性還存在一定差異性；同時其未必支持相應的基礎設施。

因此需要進行二次開發，以完善所需的基礎設施；

2.優秀的開源框架在通用性支持廣泛，提供多種選擇，同時還有一定學習成本；而面向特定領域，需要的模式相對固定。

因此需要進行定制，減少學習成本，提供開發模式，進而提高開發效率；

3.技術升級的平穩性，雖然優秀的開源框架會盡量提供升級平穩性，但是和產品目標未必一致；也需要進一步的測試工作；為了進一步減少成本和風險需要基礎平臺來處理相應工作；

4.開源框架本身存在一定的缺陷，其修復有一定周期，和產品項目周期不同步。所以也需要做些修復和規避工作；

因此開發維護支持特定領域的基礎平臺存在客觀需要。更進一步，基礎平臺是在關注點分離原則下的一個必然產物。

三、基礎平臺的考核

基礎平臺的考核需要依照其目標以及特性來，包括：

1. 功能復用所帶來的成本降低。這個比較好衡量，直接使用復用。

2. 提高業務應用的開發效率（新增或維護）。這個指標的衡量有一定難度，需要有兩個近似項目分別應用不同基礎平臺，并在一個較長時期內（比如2年，以便消除人員差異、具體功能差異性和難易度）。

3. 技術風險的可控性，技術更新的平穩性。這個指標比較好衡量，需要收集開發過程中處理各種突發技術問題以及其解決成本。

4. 招聘成本。這個指標也屬于比較好衡量的。

5. 架構推廣。架構推廣有賴于一個良好的基礎平臺，避免成為空中樓閣。

總之，基礎平臺的應用將使開發和維護的成本具備平穩性和收斂性。

四、基礎設施的選型

應考慮幾點：1. 商業角度的維護性和升級性；2. 組織的學習和管理能力；3. 基礎設施自身功能以及所支持的開發效率.以下是詳細要求：

五、基礎平臺的構建

選取基礎設施之后就根據需要進行二次開發。包括如下內容：

1. 平臺的核心

1.1 領域化支持

領域化的核心是建立業務相關的領域模型以及領域服務。

領域化支持需要三個方面：

A. 持久層支持：這個是領域化支持第一個要素，持久層能夠持久化并重建領域模型。

從持久化的方式來看可以分為文件形式和數據庫形式，以及二進制形式或文本形式。由于數據庫的廣泛使用，ORM是常見的方式；但有時這不夠，我們可能還在此基礎上，進一步擴展提供二進制或文本形式的持久化策略。

B. 業務邏輯支持：包括兩個方面：a. 領域模型涉及到的業務邏輯依賴；b.領域模型的并發支持；c. 領域服務的構建；

C. 界面層支持：包括延遲加載以及長會話支持；

領域模型雖然包括所有的數據，但考慮到性能，以及特定界面層所需要的數據通常是子集，因而界面層延遲加載異常重要。而領域模型跨界面傳遞，即長會話操作，也成為一種必然。

1.2 組件化支持

在組件化技術上，業界現有的規范和開源實現，尤其OSGi和SCA都提出了各自的組件規范，并且OSGi和SCA有融合方案。但是總體上看，由于其關注的組件元素是最為經典的，在實踐應用上還需要有一定擴展。

基礎平臺需要提供一個簡易的組件支持框架，可以支持掃描，識別并加載組件下的各種技術類型資源。包括：界面擴展點，國際化消息文件，應用服務，監聽服務，領域模型，配置數據（包括初始數據和運行數據），以及數據庫表；

主要包括如下功能：

0. 組件的加載和運行（依賴檢查）；

分為兩個層次：部署期，即部署幾個組件就加載幾個組件；運行期，根據運行期信息，加載和運行組件。部署期組件體系相對于運行期較為簡單，實際上部署期可以完全不考慮組件的邊界，而直接加載組件內的不同技術工件；而運行期需要嚴格明確組件的邊界。

1. 組件間集成和交互方法：同步異步，進程內或分布式），包括UI，服務，對象和數據庫；

2. 組件間集成和交互的上下文數據傳遞，如權限和事務等待；

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

1.3 產品化支持

    產品化支持包括了兩個方面：

    參數化支持：用戶可以通過修改預定義的參數設定調整系統行為。

    定制化支持：包括兩個層面：1.用戶定制化，即用戶通過系統提供的工具進行的定制化；2.系統定制化，即通過開發人員進行編碼開發提供的定制化。

1.4 平臺化支持

       框架提供相應的事務管理，集成支持和并發處理等等涉及各個技術支持，使得業務應用僅需關注業務邏輯。

2. 平臺的功能支持

0. 業務事務與日志

這里提的業務事務，是不同于數據庫所提供的物理事務。以B/S應用為例，一個業務事務，對應如下：

a. 一個業務事務：一個web請求，一個服務調用，一筆數據更新；

b. 一個業務事務：一個web請求，多個服務調用，多筆數據更新；

c. 一個業務事務：多個web請求，n個服務調用，多筆數據更新；

對于a，業務事務和物理事務的邊界是一致的；而對于b和c，顯然，由于物理事務和業務事務邊界的不一致性，導致基于傳統的物理事務是無法跟蹤一個業務事務所帶來的數據變更。

為了可以跟蹤業務事務，就需要通過建立業務事務及其業務日志來記錄并跟蹤數據的變化。取決于業務應用，更多的時候，只需要跟蹤相應歷史數據即可。

此外，若需要提供分布式事務（不依賴特定的商業產品），也需要業務事務和日志的支持。

1. 系統操作日志

系統操作日志通常是審計相關的。在嚴格的審計要求下，業務日志可以提供完整的數據跟蹤能力。操作日志相對于業務日志，較為簡單，只需要跟蹤相應的歷史數據。

2. 安全體系

現有基礎設施大都提供了豐富了安全體系。不過開源框架尚未提供一種基于數據庫，可以由最終用戶配置的安全體系。

基礎平臺需要在如下方面加以完善：

a.    開放角色定義；

b.   開放角色可訪問資源定義；

c.    開放角色可訪問數據定義；

實際上，b和c是a的基礎，只有角色的資源和數據可以定義，角色定義才有意義。

此外，對于可訪問數據定義，還存在一定爭議，認為此是業務范疇，基礎平臺或框架不做處理。若要在基礎平臺提供支持，可以有兩種策略：在業務層檢查和在數據連接層增強。業務層的檢查通常通過AOP技術進行，此種方法存在一定的性能消耗問題，且其適應性存在局限；而數據連接層，則是針對最終的sql語句進行解析和增強，由于SQL是標準，其適應性更強些。

3. 批處理服務

批處理或者說batch處理。

支持不同的觸發策略：定時以及手動策略；支持批處理的多步驟處理，包括步驟同一數據、不同步驟不同數據，后一步驟處理前一步驟成功的數據；提供不同的控制策略：包括中斷以及暫停；支持不同的批處理策略：串行和并發；支持不同的事務控制策略；完善的運行日志支持；支持不同的運行策略：單機和集群；

4. 打印和報表

對于信息系統來說，打印和報表這兩塊幾乎是少不了的。

一方面是打印和報表通常都需要通過第三方支持來加以實現，一定的開發模式有助于降低學習成本并提高開發效率；另一方面是針對不同應用領域，打印和報表本身存在一定管理需求。

5．系統診斷支持

3. 平臺的開發模式

0. 國際化支持

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

1.文字消息國際化

對于異步操作或者分布式操作，以及操作日志而言，文本消息并非直接呈現，而是存儲于數據庫或者文件，并在用戶查詢時呈現。此時若存儲的是國際化后的文本消息，則有局限性：文本消息在產生時決定，而非查看時決定，它的假定是系統的所有用戶都是同一個Locale；但是對于擁有多locale用戶的系統，因此支持文本消息存儲信息為非國際化后結果，而在查詢時根據用戶的區域轉換為合適的國際化文本消息；

2.布局國際化

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

若要支持兩者布局方式的自由轉換，在界面不能采用傳統的表格布局。同時，label和輸入輸出控件必需是一個邏輯控件。現有的大量的控件設計都不是如此，label是獨立的。因此也封裝新的表格控件；

3.業務時間

大部分情況下，一個國家通常只有一個時區，而像美國，俄羅斯這樣跨多個時區的國家相對較少。若一個業務系統的用戶跨越了多個時區。系統就面臨業務時間的處理。即用戶的時區和系統所在時區不同。

系統處理業務時必需同時記錄兩個時間，一是用戶所在時區時間，一個是系統時間。而業務程序在處理數據時，必需指明當前采用的時間類型。

此外，數據庫層面還需要考慮，并非所有數據庫支持記錄時區。

4.計量單位，多幣種；

國際化面臨的另一個問題就是度量衡問題，常見的有英制，美制。用戶自行轉換制式會帶來使用上不便。由基礎平臺提供封裝并自動轉換能力。

另一個更為重要的問題時多幣種問題。通常發生的交易系統上，交易貨幣和本位幣的不同。系統必須同時記錄兩個幣種，以幫助統計匯兌損失。

1. 異常體系

異常體系的設計

A.異常體系原則

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

B.異常的應用：

異常用于提示（人工處理）或者用于驅動流程。實踐中，由于兩點原因使得異常通常用于提示（人工處理）而非驅動流程。

B.1.由于異常屬于正常流程體系外的輸出，屬于不受歡迎的輸出。通常系統上出現異常后，程序也無法做相應的處理。

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

C.異常的分類

異常分為校驗錯誤，業務告警，業務異常和框架異常

C.1.校驗錯誤通常是一種輕量的業務異常，校驗錯誤所依賴信息單一或較少。

C.2.業務異常通常為用戶業務數據錯誤導致的異常信息，通常依賴較多的數據和邏輯。因此針對此類異常只要以友好的方式展示在UI上，用戶通過修正輸入等方式解決。

C.3.框架異常則是基礎平臺自身錯誤，用戶無法通過界面操作加以解決，需要開發人員介入修正。

2. 多任務處理

多任務處理包括了異步操作和并發處理兩部分內容。多任務處理在技術上屬于一個較難的部分，開發以及測試的成本都比較高。

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

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

并發策略（鎖）不僅僅是基礎平臺提供相應框架支持，還是涉及到應用系統的設計包括模型及其服務。這點上目前沒有通用的并發框架，只能是根據特定應用領域，制定相應的支持。

并發操作支持，系統提供元數據，自動分解輸入參數集合，進行并發處理（可參考Terrecota）。

3. 應用交互模式

基礎平臺提供基類，同時支持一些約定，封裝常用的開發模式，如CRUD，以及異步控制等等面向特定交互應用的開發模式。

4. 平臺的類庫

0. 工具類

包括類操作，對象操作，斷言操作，容器操作等。

1. UI控件

雖然基礎設施以及開源界提供豐富的UI控件。但是還是存在一些不足。

第一是UI控件適配性不足，應用系統已經提供各個模型以及服務，但依然需要寫代碼，而非配置方式；需要基礎平臺對已有控件擴展，提供適配能力，使得應用組件通過配置將數據暴露給UI控件，從而使得應用組件關注于業務邏輯。

第二是UI控件的國際化支持，詳見3.0國際化支持。

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

2. 文件操作支持

3. 網絡通訊支持

包括底層網絡通訊（底層網絡協議）支持，以及上層網絡通訊（應用網絡協議，如Web Sevice，RMI等）。

4. 參數化支持

5. 平臺的工具

1. 打包工具

2. 部署工具

3. 設計工具

4. 生成工具

無論何種工具都是幫助提高工作效率。即它不解決業務和技術的核心問題（核心問題的解決依賴于整體設計方案），而是提供一個加速器，處理所謂的臟活累活。