作者：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.技術選型分析
由於架構涉及衆多底層技術，也應給出相應的選型分析。
