淺談企業應用架構

作者：Anders小明

2009年5月5日

一、什麼是架構

    在牛津高階詞典（第7版）中，架構（architecture）一詞的解釋是：the design an structure of a computer system，而架構師（architect）一詞的解釋是：a person who is responsible for planning or creating an idea， an event or a situation.

    針對于企業應用，依據不同的關注點，架構可以分為如下幾類：

    業務架構（Business Architecture）：關注于業務及其流程；

    應用架構（Application Architecture）：關注于應用系統設計；

    基礎架構（Infrastructure Architecture）：關注于基礎技術；

    資料架構（Data Architecture）：關注于資料存儲及其規劃；

    這裡所說的企業應用架構，即屬于應用架構，包括如下幾個部分：

    1.目标和願景。即應用系統所面臨的問題域。

    2.評價名額。從哪些緯度和名額來評價和度量解決方案。

    3.原則和方法論。為解決這些問題，所采用的原則及其方法論。

    4.技術架構。架構的技術層面，給出相應的設計以及結構，描述應用系統。

    5.組織因素。架構的組織層面，組織的各個部分如何參與。

    二、架構的目标和願景

    1. 架構的問題來源

    1.     外部，客戶要求包括了業務和技術上。

    2.     内部，組織管理、項目管理和技術發展上。

    特别的，架構需要解決的非業務問題包括如下：

    A.系統目标：系統性能，穩定性等。

    B.項目目标：開發成本，項目品質等

    C.項目過程：需求的不确定性和開發過程的團隊協作性，即所謂的開發管理。

    2. 架構的核心問題

    問題可分解為兩種類型，業務上和技術上。

    1. 業務上。問題域分解為，邏輯的縱向抽象層次，以及邏輯的橫向子產品分解和內建。

    2. 技術上。問題域分解為，縱向的技術主題，以及橫向的技術職責的分解和內建。

    A.領域化

    傳統的架構模式是三層或者四層模式，雖然從技術上有效的橫向分解系統結構，但對業務模型如何建立，如何進行層次間傳遞，模型間關聯關系，以及與服務邏輯耦合等問題沒有給出進一步的細化，也帶來了很多問題。

    此外，在傳統設計方法下，分析模型和設計模型的轉換也是一個大的問題。

    B.元件化

    實施元件化或者說子產品化，其需求分為兩個層面。

    1.内部管理，可以幫助開發過程中進行業務切分，幫助控制進度，降低風險，以及财務分析；對于大型複雜的項目，也有利于知識的傳遞和積累。

    2.銷售需要，All in one的系統因不符合發展趨勢而不利于銷售；元件化有助于産品銷售，可以針對客戶，将若幹元件打包銷售，同時減少內建的風險。

    C.産品化

    C.1 定制化問題

    定制化問題的由來：1.面向行業的應用通常沒有标準，或者完備的标準；2.通常産品的開發是針對于通用或者公共需求，不針對于特定客戶；3.而一個确定的客戶，其自身的業務差異和管理差異導緻需求的差異性。

    這種現象尤其在缺乏标準的行業應用中，以及系統的産品化過程中。

    傳統的簡單的解決方式是為每個客戶單獨維護一個系統分支，在此情況下提供維護和更新，則維護成本巨大；是以如何解決領域的定制化就成為一個重大問題。

    C.2 更新問題

    領域需求每次進一步的挖掘和實作，都意味着領域的更新。但更新面臨的諸多問題：資料遷移，舊版本的相容問題，依賴關聯等等，在元件化和定制化情況下，還面臨定制化相容和沖突檢測。

    C.3 國際化問題

    1.文本消息國際化

    國際化消息沒有直接呈現，而是中間存儲後呈現；

    2.布局國際化

    阿拉伯人是從右到左；

    3.業務時間，跨時區；

    4.計量機關，多币種；

    D.平台化

    應用系統可以分為兩個内容：應用程式和基礎設施。應用程式處理業務問題，而基礎設施處理技術問題。

    來自客戶的要求是包含業務和技術兩個方面。其中技術上包括兩種“定型和定性”，其所需的知識和技能是不同于業務上的；

    此外，内部管理也提出相應的要求。由于技術的發展和業務發展之間的不同步，對于一個産品而言，同時存在技術更新和業務更新兩個需求。而同時更新存在較大的成本和風險。

    同時對于一個産品來說，技術方面需要較強的适應性，能夠低成本上的适應客戶的特别要求。

    是以有效解藕技術和業務兩個部分成為必然。

    3. 架構的應用問題

    A.事務管理

    資料一緻性問題出現的原因通常是開發過程中，由于錯誤的并發和事務控制導緻的；而在業務過程中也存在錯誤的業務操作情況。

    B.并發處理

    不同的業務應用存在不同的并發場景（并發度以及存在的業務依賴），是以業務上需要明确原則和方案；而不同平台所支援的并發方式和能力也不相同，則采用一定架構支援有助于簡化問題。

    C.內建能力

    業務應用所面臨的內建問題不同，包括不同的內建環境：外部系統，内部系統，遺留系統等；不同的內建模式：基于檔案，基于資料庫表，基于消息等，導緻所需的內建方法及其能力也不同。

    4. 架構的設計問題

    分析設計和開發實作存在着一定的差異性：分析設計屬于知識級，而開發實作屬于操作級的。

    分析設計是需求和實作的中間橋梁，因而設計必須解決系統邊界的合法性，内部邏輯解藕的合理性和實作的可達性（設計的類方法為實作的30%-70%）。而開 發實作需不斷重構代碼，采用約定和架構能力等技術手段解決開發的實際問題，解決程式級别的健壯性，可讀性，可維護性以及可測試性。

    傳統的方式，分析設計存在于文檔中，而開發實作存在于代碼中。兩者的割裂導緻溝通的困難，也導緻了開發工程中具大的風險——分析設計和最終開發實作的不一緻性。

     三、架構的評價名額

    1. 财務角度

    在傳統的财務核算機制中，系統或者産品的開發通常屬于成本中心，對于IT企業來說，電腦裝置，辦公室等屬于沉沒成本，而IT人員的工資屬于可變成本，是成本的核心部分，為了控制成本，就需要減少項目的開發時間。

    是以架構一個重要的關注點在于控制開發成本和維護成本，通常講維護成本是開發成本的3倍。降低開發成本核心，在于提高效率、提高适應需求變化的能力。

    2. 技術角度

    技術角度評估架構很難說一個架構行或者不行。技術角度需要給出的最大名額是風險性。而風險性和各個名額因數有很大相關，但還需要結合相應實際情況判斷。例如：如果決定了不可能換資料庫，那麼即便強綁定oracle也沒有特别的風險。

    以下名額參考了架構的品質特性，但進行了裁減。

    A.内部名額

    1.侵入性。或者說是可遷移性，即系統與外部資源的關聯關系，以及系統内部的關聯關系。例如，如果架構決定使用pl/sql，那麼就意味着架構和Oracle資料庫是強綁定。

    2.重複性。雖然我們都知道關于重複的兩個原則（1.不要重複，2.不要自己重複），但是有時重複看上去無法避免，那麼就是判斷這個重複性帶來的問題有多大。

    3.擴充性。即架構提供何種條件下的何種擴充和變化能力，及其成本。

    4.平穩性。在業務或技術擴充時的，架構所呈現的發展态性。

    5.抽象性。即可視性，并包括了概念完整性。系統是否完整以及階層化的反映應用問題，能否明确的呈現和表達。

    6.修改性。包括了可重構性，代碼級别的侵入性以及單元測試能力。

    7.診斷性。系統提供的實時觀測能力。

    B.外部名額

    1.性能。

    2.可靠度。

    3.可用度。

    3. 組織角度

    組織角度涉及兩個方面：人和流程。

    人的方面，架構需要組織的角色參與（業務專家，技術專家）及其參與度，以及涉及到人力資源比對情況。若架構所需的技術如果太新或者太窄，将面臨人力資源的困境。

    流程上，要看架構是否與流程比對。架構原則指導下不同角色在不同階段關注點不同，而工程實踐中，不同流程階段需要送出的産出物也不同，此時就可能存在二者不比對的情況。

    四、架構的原則和方法論

    1. 原則

    總原則是：關注點隔離。

    在解決各類問題都應以此原則為指導。但針對于不同層面該原則的變化不同。針對于高層設計（概要設計）：合理劃分邏輯邊界；針對于詳細設計層面是：任何改動最多涉及一個接口和一個實作類（簡單類職責的變體）。

    2. 方法論

    方法論有兩個：自上而下，由内而外。

    其對應的完整理論體系為：面向對象/面向方面，領域驅動設計以及測試驅動設計。

    3. 發展與演化

    A.總結歸納型

    這個方式最常見。程式員所需要面對的問題是：在有限的時間、資源，面對有限的需求，在容錯範圍内的做出一定的産品。在這種有限條件下反複訓練出來的決策機制，使得程式員對歸納法有着特殊的偏好。它對于程式員開發的大部分工作都是行之有效的。

    B. 技術思辨型

    通過更廣泛的分析，擷取深刻的了解和普遍的關聯，以創造新穎的技術。所謂大牛們正是如此。例如GC算法，例如AOP技術。

五、架構的技術層面

（一）基礎手段

提高開發效率和品質的基本手段是分解——即充分的分離系統中不同的關注點，好處不用說了，可以并發的工作，每個人面對的問題都簡單而容易操作。而與分解對應的內建，隻有提供了好的內建能力，分解才成為現實，而隻有分解了，才能清晰的提供業務更多适應性。

分解和內建的手段分為程式設計語言和技術架構兩個層面。所謂語言就是強架構，而架構就是弱語言。

A. 開發語言

現代面向對象的語言提供如下能力：抽象和派生能力，以及接口隔離能力。實際提供兩種分解和內建能力：

1.     把邏輯分解在兩個層次中，而通過繼承的方式把兩個部分內建在一起。

2.     把邏輯的外觀和實作分解在兩個地方，而通過接口實作的方式把兩部分內建在一起。

另一種語言AspectJ或者C#語言2.0之後提供的特性：把流程邏輯，分解在不同的地方，而通過簽名比對，利用代碼生成的方式來把幾部分內建在一起。

B. 應用架構

然而語言提供的內建能力，畢竟底層，而且有限，擴充起來也格外小心。因而技術架構提供另外的內建能力就格外重要：

1. 對象關聯關系的分解和內建，如Spring提供容器管理能力

依賴注入對于依賴關系是适合的，對于服務間，技術層次間都是适合的（因為無狀态）；但對于聚合（整體和部分）的關系——主要是領域模型（有狀态的）——則不合适；

2. 子產品間關聯關系的分解和內建，如OSGi，ESB等

3. 流程邏輯的分解和內建，如Spring Web Flow以及jBPM。

4. 不同系統的類型分解和內建，如Spring利用動态代理提供的Exporter模式。

5. 模式的封裝內建，設計應當是面向服務的設計，但是服務的暴露方式以及模式可以有很多種，比如API，Web Service，RMI，以及Command模式，Event模式等，架構應該利用動态代理等技術對于這些服務暴露方式，模式進行封裝。

C. 分析設計

設計中涉及到的組合方式，包括類（接口）組合，繼承組合以及産生組合三種。三種組合各有優缺點，設計時适應不同場合。這就涉及到現有面向對象的設計粒度：類（第一公民）和方法（二等公民）。

類（接口）組合實際上複用的是類一級粒度的設計，而繼承組合本質上是一種有方向的組合，複用的方法一級粒度的設計，提供與或非的邏輯操作。而産生組合，例如AspectJ，也是在方法一級粒度的設計複用。

因為繼承組合複用在方法 一級的粒度上，因而其更适合存在嵌入式，最低粒度的差異性的設計中，借助于虛拟機的支援，無需額外工作。而類（接口）在類一級上，更适合在更高一級的邏輯複用上；其實不一定需要接口，普通的類也可以，但是在這一級粒度的差異性替換，采用接口優于類，是以稱為類（接口）組合；接口是類（接口）組合的編碼需 要；對于接口一級，需要通過架構的內建和适配來提供差異性的設計。産生組合其實也是在方法一級，不過更關注于廣泛的橫切面，同時由于現有的語言對它的支援不同，Java需要額外的編譯器，而.Net則是在内置編譯器上支援。

更高一級的組合是元件組合。對于元件邊界的設計，遵從兩點：嚴格把關設計和代碼優先。接口優先的設計通常導緻成本太高，實踐中會導緻開發人員在項目的進度壓力下把代碼寫在不合适的地方。

D. 開發方式

常見的開發方式可以歸結為3類：開發式程式設計（Programmatic programming），聲明式程式設計（Declarative programming）和産生式程式設計（Generative programming）。

開發式程式設計	聲明式程式設計	産生式程式設計
開發手段	編碼。 如：Java， C#	解析。 如：ANT(spring等的xml不一樣，它們是靜态描述型的，不那麼verb)	生成。 如：AOP（AspectJ），DSL（Drools）
開發性質	聚合	聲明	組合
代表事物	接口	N/A	DSL 自然語言的表達能力很強大，雖然說有時具有二義性，但是在特定領域下是确定的，既然是講DSL，那都是特定領域相關的，一定是明确的。
基礎設施	解析器； 編輯器，如jbpm； 元模型；	生成器； 正統的需要編輯器； 元模型
開發方式	自上向下，聲明式程式設計是解析概念，用統一的概念來了解，把不同差異性交由具體程式解析； 編輯器生成的是xml檔案，将由架構程式解析； 聲明式是粗粒度的（不能直接比較大小，定義的是無差異性的概念）；	自底向上，産生式程式設計用的思路是組合概念（用小粒度的概念組合生成大粒度的概念）； 産生式生成程式代碼，不做解析運作； 産生式是相對細粒度的；

E. 小結

通常語言作為架構的基礎，語言的設計帶來的好處遠遠高于架構和模式，但其引入和更換也是有巨大風險的；而通過提供強大的架構能力，架構盡可能多的完成技術問題，并通過中繼資料，模式以及約定降低業務和架構的耦合。避免因為架構更新帶來不必要的成本。

Meta Programming的最高層次是語言級别直接解決，比如，Smalltalk, Ruby, Python, 還有其他Reflection支援的非常好的語言。甚至STL等template技術，也可以算作語言級别。 Code Generation 是最低級别的Meta Programming解決方案,技術含量也最低。這個級别必須超越，才能夠真正達到質變，完全跳出概念炒作的層次。

從技術手段上，提高開發效率的另外兩個手段是代碼生成和類庫引用。但代碼生成和類庫引用，都隻解決了邏輯的分解能力，沒有提供內建能力，是以一般情況下需要提供架構內建，尤其代碼生成需要在系統的最外層，避免內建帶來的問題。

代碼生成也沒有那麼壞，關鍵在于生成什麼，如果是生成結構性的代碼，由于往往不是最終的産物，就存在同步維護問題；同時這種代碼是大都可以用template完成的。

但如果生成的是功能性代碼，這類代碼是最終執行代碼，那麼通常就把用于設計的代碼看作是最終産物，最明顯的例子是DSL。

（二）核心問題

1. 領域化

領域化，即領域模組化。通常而言，領域模型設計中，子產品分解，抽象分層和職責分層都是重要手段。問題域為：流程，領域模型和領域服務（包括規則）。

a. 對象的抽象分解和內建

b. 對象的依賴分解和內建（子產品内和子產品外）

c. 流程的分解和內建（頁面流，工作流以及計算流程）

d. 程序邊界：使用者請求重定向，以及業務資料持久化等。

對于中等項目來說，系統中應該有50-100個領域對象代表了業務抽象；

2. 元件化

面向對象語言本身沒有提 供的元件級别的依賴關系內建能力。語言不提供，因為領域元件的粒度太大，超越了語言的範疇。但我們可以通過架構提供，在Java體系中，目前已經有兩個較 好的解決方案：OSGi（JSR291）和SCA。可以很好的解決元件服務依賴關系管理，包括熱替換。

同時另一個問題——邏輯分層的問題：如保險産品面臨的核心層，國家層以及公司層三個邏輯層次分解和內建能力。這點的解決方案可以通過OSGi + Spring來解決，包括了靜态差異性替換和動态差異性替換。

還有元件邊界保護問題，我們希望限制别的元件通路本元件内部實作，有兩種手段可以完成，1是送出/部署時，通過在代碼送出時的代碼檢查工具，或者釋出時編譯工具完成；2是通過OSGi的邊界限制能力。

3. 産品化

A. 定制化支援

領域定制化涉及到邏輯替換問題。邏輯的替換根據開發方式不同，有兩種類型：基于接口和基于繼承；

A. 基于接口（包括了靜态替換和動态替換）

1. 靜态替換是Override，在OSGi中隻要停止原有服務，啟用新服務即可，而在Spring中更改相應配置檔案即可；

2. 動态替換，其實是指運作時Condition Service Locator，在OSGi中可以利用Extension Point（Plug-in）解決，而Spring中隻要提供一個類似Service Locator就可以。

B. 基于繼承（或者靜态類）

1.開發時，直接修改源代碼編譯；

2.編譯時，采用AspectJ，在編譯時提供替換；

3.加載時，開發一個新邏輯的同名類，但其加載路徑優先于原有類；

B. 更新支援

主要是增量更新支援，以及有限的降級支援。同時要考慮到對于定制化産品的更新支援。

4. 平台化

A.基礎設施

基礎設施包括：類庫和架構。基礎設施可以自己開發，或者應用第三方（開源商業）實作。

A1. 基礎設施的選型

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

客戶角度
成熟度要求	基礎設施是業界成熟方案；
性能要求	基礎設施滿足系統運作的性能要求；
穩定性要求	基礎設施版本穩定,經過大量測試；
環境性要求	基礎設施不會帶來額外的軟硬體相容要求；
管理角度
開發成本要求	基礎設施的開發維護成本低,最好是業界成熟開源成果；
開發效率要求	基于該基礎設施的應用開發效率高；
維護成本要求	分析設計與開發之間的銜接性好；
測試成本要求	基于該基礎設施的應用測試成本低,效率高；
教育訓練招聘成本要求	網絡上的參考資料豐富性;基礎設施的流行度； 内部員工學習教育訓練成本低; 招聘外部員工成本低；

A2. 基礎設施的內建

基礎設施獨立後，出現平 台化的發展趨勢，這個趨勢有兩個方向：通用化和專業化。通用化意味着基礎設施和應用的距離加大，易用性減低；而專業化意味着适應性的減少。這是一個沖突體。在基礎設施選型後，再進行一定內建工作，可以結合目前情況，平衡易用性和适應性；同時合适的內建也有助于隔離技術和業務兩個方面。

從維護更新角度看內建的合适性：對于沒有标準的，不要做不必要的封裝，封裝等于是建立一個标準，而這是不現實的；應當盡可能采用架構方式，屏蔽基礎設施對于應用程式的侵入性。如果是标準，就更沒有必要封裝，畫蛇添足。

B.業務支援

B1. 基本原則和手段

基本原則是：應用程式POJO化。減少技術對于業務侵入性。主要手段是：容器上下文；依賴注入；AOP技術；中繼資料支援；事件機制；開發工具和代碼生成；

依賴注入+AOP+中繼資料構成了簡單對象(POJO)的支撐技術。基于此三位一體的技術可以有效的隔離業務問題和技術問題，更為甚者它可以支撐簡單對象體系，每個對象做且隻做一件事。

B2. 開發模式與最佳實踐

基礎平台應該提供業務相關的模式封裝。

B3. 關于中繼資料

中繼資料有多種：語言級别為Annotation(微軟.NET為Customer Attribute)；架構級别可以是XML檔案或者其它配置檔案。

中繼資料可以通過以下幾個視角觀察

1. 應用層次：中繼資料代表了業務含義和技術含義；

2. 技術分析：文檔類型（開發管理型）；編譯類型（類加載型）；運作期行為。

3. 實體分析，包括Annotation和接口，XML檔案，甚至是EL和類。

中繼資料系統的建立其實是代表了認知過程。

以運作期的中繼資料為例，代表了系統通過反射擷取相關中繼資料來自适應系統，其實際意義在于将軟體設計開發人員對于系統的認知通過技術手段固化下來。

中繼資料系統的開發目的有兩個：

1. 業務應用上，提供業務動态能力；

2. 技術應用上，簡化開發減低成本；

這裡面有一個誤區是：為了技術應用而過分地開發中繼資料系統，而随着業務的演化導緻為技術應用的中繼資料迅速被抛棄，導緻投入的浪費。實踐中要避免。

（三）應用問題

1.事務管理

A. 成熟的事務技術：如資料庫；

B. 合理的并發設計控制；

C. 完整的業務日志；這也是解決業務回退的主要手段；

D. 輔助的資料校驗能力；

并發設計控制和完整的業務日志，是架構設計中保障資料一緻性主要着力點。并發設計控制，需要結合業務，通過悲觀鎖定來保障。

而業務日志的擷取則面臨 着諸多困難，主要是業務事務和實體事務的不一緻性（即一個業務事務可能橫跨多個實體事務，也可能一個實體事務包括多個業務事務）；業務日志控制層面有兩個：應用系統或基礎設計；通過應用系統編碼控制，則不可避免的提高了應用系統開發和測試的成本；通過基礎設施控制，有助于減低成本，但提高基礎設施的設計 成本；

2.并發處理

    分析業務所涉及的并發場景，制定相應的原則和方法，并合理選用現有的并發處理架構，進行一定程度的剪裁，通過架構支援和簡化這些原則和方法的實踐。

3.系統分解

基于應用的層面的分解，有多個緯度，包括：業務抽象度，業務任務，業務産品線，以及業務領域等等。

4.內建能力

軟體開發的适應性在于分解粒度的大小，而分解粒度大小取決于內建能力。

1）依賴管理

在技術的角度看，軟體系統是一個存在大量依賴關系的對象系統。其中包括了兩種依賴：

1.業務代碼的對象依賴；比如調用一個工廠類建立一個對象。

2.業務代碼的環境依賴；它可能依賴于一個Web環境（讀寫Request和Response流），資料庫系統（讀寫資料記錄），檔案系統和網絡系統等。

不幸的事是這種代碼量占據了大量的開發工作。重複的開發工作（對象或者資料的依賴關系維護工作）減低了開發效率和系統适應變化的能力。

而這樣複雜依賴關系也給軟體的測試帶來了相當大的困難需要搭建足夠的依賴環境（如一台Web伺服器和資料庫伺服器），甚至是硬調試。

于是就有了采用第三方代碼來完成依賴關系維護工作的思路，所謂的依賴注入。業務對象出現Spring等著名架構

動态代理技術則解決了提供支撐環境封裝的問題。比如提供網絡通路能力(如RMI，URL和Web Services)，檔案通路能力(如xml、property檔案讀寫)。

由于企業開發中資料庫技術的應用不可避免，因而ORM架構的出現還有特别的意義，在它的支撐下，核心業務西可以嚴格差別領域邏輯和業務邏輯，而這在以前是做不到的。

AOP開發的出現解決了面向對象下的橫向組織關系。從一定程度上看，AOP可以看作是另一種依賴關系，可以另外依賴注入來實作。當然也可以采用程式設計實作。

2）資料對象

說起內建，就不得不提到一種類型的對象存在——VO對象。

VO對象是為了內建而存在的；其意義是：1. 保護系統的資訊邊界，提供一種結構可以使其它系統或者元件通過編碼方式擷取系統内資訊的方式；2. 保護系統的事務邊界，領域對象技術上攜帶着持久化資訊，通過VO可以屏蔽得以屏蔽。常見的VO對象存在于Web層和Domain層。

是以，VO對象的存在隻是為了內建而存在，其是否存在的取決于兩個方面1. 內建的設計結構；2. 架構的兩個能力——對象路徑通路能力以及事務邊界管理。

Domain層VO對象，通常是用于不同領域元件間的互動，但随着架構的改進，內建代碼獨立存在而不再嵌入到元件内部，元件的邊界問題保護不複存在；更進一步的是，架構提供自動化的接口适配映射能力的增強。因而VO對象失去存在的意義。

Web層 VO對象，以SWF為例，早在SWF 1.x時代，架構就提供了豐富的對象路徑通路能力，但其Web互動是典型的MVC2方式，事務邊界在view的render前關閉，因而導緻需要特定的 VO對象來避免持久化資訊問題；而SWF 2.x時代，view的render是在事務邊界内，VO不再需要。

系統設計是一種結構化過程，邏輯和資料被分解和內建到系統的各個部分；在運作期，真正重要的是結構化路徑通路能力，換句話說重要的是結構化後的路徑，而實際用何種資料結構其實不重要。

可以使用資料樹Data Tree形式，提供扁平化的資料通路能力，是一種較好的開發方式，極大的提升了開發效率。Spring Web Flow以及其它架構廣泛的運用EL提供統一的表達式通路資料，也大大降低了開發成本。

3）事件機制

事件機制應用非常廣泛，是很重要的內建手段。事件機制的優勢在于其提供了松散耦合而帶來的擴充能力。基于傳統事件模式，可以擴充提供同步/異步，事務隔離等額外控制能力。

4）元件設計

一個元件包括了API和SPI，其中API是用于客戶方程式設計，SPI用于服務方程式設計（屬于架構回調）。無論是API和SPI都是該元件所有，展現了一個元件自身的完備性。其與其它元件依賴通過內建子產品完成，依賴解藕。

元件的設計還分層次，上層元件的邏輯依賴下層元件，上層元件直接通路下層元件的服務和模型，保持單向依賴有助于降低開發和維護成本。而平級元件，由于元件的替換可能性大，因而保障元件邊界完整性尤為重要。

接口的實作是關鍵。面臨 的問題是，在開發初期需求不确定和經驗不足的情況下，接口的設計不盡合理，導緻需求變動後，所進行的修改将影響三個方面，接口、接口實作對象和測試用例。工作量将可能很大。特别是在并行開發過程中，一個通訊接口的變化将可能引起很大連鎖反應，導緻其他成員不得不停下手上的工作。

因而在實際開發中需要做個權衡。不同子產品的通訊接口應該由團隊成員共同負責，一旦接口變化，接口實作成員應該提供相應的假實作。而子產品内部可以由開發人員自行設計，可以在初期不提供接口和簡單的測試用例，在項目具有一定穩定性後，利用重構實作接口和完整的測試用例。

有效定位系統錯誤。尤其在元件化和分層化，以及其它開發手段混合運用情況下。例如，A，B，C。由于C引起的錯誤導緻A錯誤是很難查的。代價很高。

5）膠水層

膠水層代碼屬于內建範疇。它是系統開發中不可避免的。膠水層代碼的存在增加了設計、開發和測試的成本。因盡量減少膠水層代碼的人工開發。

膠水層代碼有兩種類型：一是擴充卡，二是開發模式。

擴充卡對于內建來說并不陌生。擴充卡從用途上分可以分為兩種：業務适配和技術适配。業務适配是指處理應用程式接口的适配調用，消除應用程式的耦合度；技術适配是指處理應用程式和技術架構上，消除技術架構的耦合度。

開發模式是指基礎平台對于應用開發的支援減少無效代碼，例如采用ORM系統（如Hibernate）以及有狀态的Web層架構（如Seam和SWF）可以有效減少應用系統處理資料（對象）狀态；以及各種中繼資料的識别和增強。

6）內建階段

根據階段分為：設計時, 編譯（加載）時和運作時。設計時是由人工編碼，通常就是一些特定業務代碼，完成內建工作；編譯時內建工作通常指配置檔案，由程式員提供，但不需要編碼工作；而運作時指通過指定中繼資料，由架構運作時解析；

5.部署方式

部署有兩種：本地部署和分布式部署。

分布式部署會帶來額外的問題。如果支援分布式部署，有兩種方案：

1.       前後端分離方案

傳統EJB方案就是此種。面臨的問題和風險：

a)         部署成本，即分布部署帶來開發成本；

包括：分布式調用；分布式事務管理；開發模式（即上下文的傳遞）。

b)         運作成本，即分布式資料傳輸性能問題；

2.       采用Portal或類似技術

（四）設計問題

設計文檔依然有用，采用Color UML有助于閱讀。

面向對象提供各種關系的表達能力：關聯，依賴，內建，組合等；類似于資料庫表關系，但是更強烈。在設計時需要注意表現。

新的開發方式，應該可以通過代碼記錄分析設計的成果，形成系統中一個穩定的可發展的抽象層次代碼，而開發實作則繼承或者适配該抽象層次，最終保證系統可運作性。

這樣知識層面的分析設計可以有效貫徹發展，而操作層面的開發實作可以關注于實作過程的工具和手段。這樣就可以確定設計是做正确的事，而開發過程提供各種架構工具則把事做更有效率。

六、架構的展示

1.兩個要素

架構要展示的兩個基本要素是：業務和技術元件。而業務又可分為元件和功能兩個層次，技術又可分為基礎平台與元件所需提供工件兩個部分。

後續所有展示都圍繞此二要素。

2.核心視圖

由RUP貢獻的四個視圖是架構展示的核心視圖。

邏輯視圖（靜态類圖）

關注功能，不僅包括使用者可見的功能，還包括為實作使用者功能而必須提供的"輔助功能子產品"；它們可能是邏輯層、功能子產品等。

應映射為業務元件、功能包以及技術工件（分層），以及它們之間關聯依賴關系；

開發視圖（靜态類圖）

關注程式包，不僅包括要編寫的源程式，還包括可以直接使用的第三方SDK和現成架構、類庫，以及開發的系統将運作于其上的系統軟體或中間件。

開發視圖和邏輯視圖之間可能存在一定的映射關系：比如邏輯層一般會映射到多個程式包等。

應映射為具體的SDK和架構等，以及關聯依賴關系；注：開發視圖應盡可能和邏輯視圖一一對應；

處理視圖（動态類圖）

關注程序、線程、對象等運作時概念，以及相關的并發、同步、通信等問題。

處理視圖和開發視圖的關系：開發視圖一般偏重程式包在編譯時期的靜态依賴關系，而這些程式運作起來之後會表現為對象、線程、程序，處理視圖比較關注的正是這些運作時單元的互動問題。

可映射為狀态圖和活動圖（高層和詳細）；

實體視圖（部署視圖）

關注"目标程式及其依賴的運作庫和系統軟體"最終如何安裝或部署到實體機器，以及如何部署機器和網絡來配合軟體系統的可靠性、可伸縮性等要求。

實體視圖和處理視圖的關系：處理視圖特别關注目标程式的動态執行情況，而實體視圖重視目标程式的靜态位置問題；實體視圖是綜合考慮軟體系統和整個IT系統互相影響的架構視圖。

可映射為元件圖，部署說明圖；

3.擴充視圖

在核心視圖，針對于不同閱聽人，還需要提供三個擴充視圖。

非功能視圖

展示非功能性名額的支援能力。通常針對于技術人員。

基礎設施視圖

展示架構所采用基礎設施，以及它們之間的關系。通常針對于技術人員。

資料視圖

關注于資料組織和存儲形式。通常針對于DBA，或者需對資料進行定期維護的使用者。

4.原則和限制

架構因明确說明本架構采用原則、方法論以及相關限制。

5.技術選型分析

由于架構涉及衆多底層技術，也應給出相應的選型分析。