1. 程式人生 > >【平臺+原創】SOA元件化思想在專案中的落地(Primeton EOS)

【平臺+原創】SOA元件化思想在專案中的落地(Primeton EOS)

1 普元平臺的內涵

1.1 層次化

分層架構是降低軟體複雜度的最常用手段之一,從軟體的可變性管理和降低應用複雜度來講,軟體平臺必須要層次化,基於技術平臺搭建業務平臺,進行業務元件積累,再基於業務平臺進行業務應用開發。普元平臺提供了強大的技術平臺支撐,提供了統一的應用軟體架構和流程引擎,從而收斂了技術路線;同時為應用系統開發提供一致的開發、執行、管理一體化框架。合作伙伴進行業務平臺搭建和業務元件積累,並結合專案需求開發最終的業務系統。

1.2 元件化

在多應用多產品情況下,軟體平臺需要基於SOA思想和標準規範進行元件化,所支撐的上層應用則能根據需求的不同整合所需要的元件。

1.3 體系化

在多應用多產品情況下,軟體平臺需要基於SOA思想和標準規範進行元件化,所支撐的上層應用則能根據需求的不同整合所需要的元件。

2 構件化設計原則

2.1 從業務開發看構件化

2.1.1 SOA的構件化業務模型

SOA的企業應用架構體現在以下3個維度:1)業務維度:關注的是構件化/流程化的業務模型和服務構造;2)技術維度:關注的是服務化和互動協同的技術架構;3)管理維度:關注的是IT和業務的可管控和可治理框架。普元平臺從平臺的技術分層架構、管控和治理架構上對技術維度和管理維度都提供了有力的支撐。從業務維度來看,普元建議採用構件化的業務模型來支撐業務的構件化和流程化,主要分為以下幾個層面:

 業務流程:

業務構件對外提供的服務,通過業務流程組織和使用

 業務構件:

業務層面複用,解決某一業務領域的問題

 平臺構件:

平臺類的複用,例如工作流、內容管理、規則、報表等

 技術構件:

技術層面複用,例如字元處理、選單、日誌

2.1.2 構件化的業務開發與專案導向的區別

構件化的業務模型與傳統專案導向的應用模式的區別,主要是專案導向的應用模式,只從專案應用的需求出發,業務設計和資源配置只在專案組內部考慮,而沒有從業務服務複用和價值最大化的角度考慮,典型的結果就是各個專案成為“豎井式”的應用,專案資產耦合度很高、很難拆分,IT資產得不到有效的利用。當然,即便是專案導向的開發,也與整個專案的總體規劃和架構設計質量相關。

構件化的業務模型,是把日漸複雜和不斷變化的業務系統通過分層、分模組地設計分解為若干相對獨立又不相交的業務構件,並進一步分析這些業務構件對於企業總體業務的基礎性、差異化和核心度,然後再針對性地實現、改良和革新。通過統一的業務藍圖規劃和業務模組分析來實現統籌分治,是把複雜問題進行統籌和分而治之的一種業務設計模式,並根據企業的業務目標和關鍵業務指標(KPI)來分清各個業務模組的輕重緩急策略。這種模式在業務服務的物理部署上也更為的靈活,業務構件的模組獨立性和規範性帶來了更好地計算資源配置和虛擬化部署,進一步提升了IT的資產效率。

2.2 構件包設計原則

構件化的設計思想在普元平臺上的落地,最典型的就是構件包的設計。構件包是普元平臺系統釋出和複用的基本單位,它由邏輯流、頁面流、服務構件、Java程式碼、頁面資源等組成。既然構件包作為普元平臺資產管理和複用的基本單位,那麼構件包的劃分的合理性也就直接影響了業務系統最終的可管理性和可複用性。一個構件包通常能夠完成一個相對獨立、完整的業務功能。

一個構件包相當於一個業務模組,對應於應用系統中一個相對獨立的業務域。一般原則:在總體設計時進行構件包規劃和設計,模組進行切分時大小適中(功能相對獨立和完整,適合1-2人獨立完成), 粒度太大會影響業務的複用;粒度太小會增加管理複雜度。每個構件包對應一個與其名稱一致的web路徑。一般可複用的通用功能或頁面可單獨抽取到一個公共構件包中。被多個模組呼叫的基礎業務資料和功能最好作為獨立的構件包存在。劃分構件包時應避免構件包之間的相互依賴,如構件包A依賴構件包B的資源,而構件包B又要使用構件包A的資源,這時應該將構件包A,B相應的資源抽取到公用構件包C。

合理劃分構件包的另一個好處是構件間的依賴和引用關係非常明確,如果出現迴圈引用,系統會自動進行檢查和提醒,對於程式碼的重構和修改系統也可以直接反應影響範圍,便於進行管理和維護。每一個構件包都可以有獨立的版本管理,可以獨立發展和變更,便於進行後期的運維。

3 流程設計改進建議

3.1 流程設計原則

流程設計需要遵循KISS原則(keep it simple and stupid),儘量保證流程的簡單和清晰。這樣便於流程的監控和改進。在流程分析設計過程中儘量保證流程的清晰完整,儘量做到一個流程只做一件事情。

3.2 現狀描述

目前專案只設計了一個大的業務流程,把業務管理的各個環節全部在該流程中囊括了。

3.3 改進建議

建議按照業務管理的各個階段對流程進行拆分,定義一些相對獨立的子流程,再通過子流程串聯形成完整的業務管理大流程。這樣,每個小流程發生改變時只需要對一個子流程進行調整,而不是針對一個複雜的大流程的具體細節進行調整。同時,抽取一些可能複用的子流程,有些流程如:簽收流程可能會被多個不同的子流程複用。