五、架構(gòu)的技術(shù)層面

（一）基礎(chǔ)手段

提高開發(fā)效率和品質(zhì)的基本手段是分解——即充分的分離系統(tǒng)中不同的關(guān)注點，好處不用說了，可以并發(fā)的工作，每個人面對的問題都簡單而容易操作。而與分解對應(yīng)的集成，只有提供了好的集成能力，分解才成為現(xiàn)實，而只有分解了，才能清晰的提供業(yè)務(wù)更多適應(yīng)性。

分解和集成的手段分為編程語言和技術(shù)框架兩個層面。所謂語言就是強(qiáng)框架，而框架就是弱語言。

A. 開發(fā)語言

現(xiàn)代面向?qū)ο蟮恼Z言提供如下能力：抽象和派生能力，以及接口隔離能力。實際提供兩種分解和集成能力：

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

2.     把邏輯的外觀和實現(xiàn)分解在兩個地方，而通過接口實現(xiàn)的方式把兩部分集成在一起。

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

B. 應(yīng)用框架

然而語言提供的集成能力，畢竟底層，而且有限，擴(kuò)展起來也格外小心。因而技術(shù)框架提供另外的集成能力就格外重要：

1. 對象關(guān)聯(lián)關(guān)系的分解和集成，如Spring提供容器管理能力

依賴注入對于依賴關(guān)系是適合的，對于服務(wù)間，技術(shù)層次間都是適合的（因為無狀態(tài)）；但對于聚合（整體和部分）的關(guān)系——主要是領(lǐng)域模型（有狀態(tài)的）——則不合適；

2. 模塊間關(guān)聯(lián)關(guān)系的分解和集成，如OSGi，ESB等

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

4. 不同系統(tǒng)的類型分解和集成，如Spring利用動態(tài)代理提供的Exporter模式。

5. 模式的封裝集成，設(shè)計應(yīng)當(dāng)是面向服務(wù)的設(shè)計，但是服務(wù)的暴露方式以及模式可以有很多種，比如API，Web Service，RMI，以及Command模式，Event模式等，框架應(yīng)該利用動態(tài)代理等技術(shù)對于這些服務(wù)暴露方式，模式進(jìn)行封裝。

C. 分析設(shè)計

設(shè)計中涉及到的組合方式，包括類（接口）組合，繼承組合以及產(chǎn)生組合三種。三種組合各有優(yōu)缺點，設(shè)計時適應(yīng)不同場合。這就涉及到現(xiàn)有面向?qū)ο蟮脑O(shè)計粒度：類（第一公民）和方法（二等公民）。

類（接口）組合實際上復(fù)用的是類一級粒度的設(shè)計，而繼承組合本質(zhì)上是一種有方向的組合，復(fù)用的方法一級粒度的設(shè)計，提供與或非的邏輯操作。而產(chǎn)生組合，例如AspectJ，也是在方法一級粒度的設(shè)計復(fù)用。

因為繼承組合復(fù)用在方法一級的粒度上，因而其更適合存在嵌入式，最低粒度的差異性的設(shè)計中，借助于虛擬機(jī)的支持，無需額外工作。而類（接口）在類一級上，更適合在更高一級的邏輯復(fù)用上；其實不一定需要接口，普通的類也可以，但是在這一級粒度的差異性替換，采用接口優(yōu)于類，因此稱為類（接口）組合；接口是類（接口）組合的編碼需要；對于接口一級，需要通過框架的集成和適配來提供差異性的設(shè)計。產(chǎn)生組合其實也是在方法一級，不過更關(guān)注于廣泛的橫切面，同時由于現(xiàn)有的語言對它的支持不同，Java需要額外的編譯器，而.Net則是在內(nèi)置編譯器上支持。

更高一級的組合是組件組合。對于組件邊界的設(shè)計，遵從兩點：嚴(yán)格把關(guān)設(shè)計和代碼優(yōu)先。接口優(yōu)先的設(shè)計通常導(dǎo)致成本太高，實踐中會導(dǎo)致開發(fā)人員在項目的進(jìn)度壓力下把代碼寫在不合適的地方。

D. 開發(fā)方式

常見的開發(fā)方式可以歸結(jié)為3類：開發(fā)式編程（Programmatic programming），聲明式編程（Declarative programming）和產(chǎn)生式編程（Generative programming）。

E. 小結(jié)

通常語言作為架構(gòu)的基礎(chǔ)，語言的設(shè)計帶來的好處遠(yuǎn)遠(yuǎn)高于框架和模式，但其引入和更換也是有巨大風(fēng)險的；而通過提供強(qiáng)大的框架能力，框架盡可能多的完成技術(shù)問題，并通過元數(shù)據(jù)，模式以及約定降低業(yè)務(wù)和框架的耦合。避免因為框架升級帶來不必要的成本。

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

從技術(shù)手段上，提高開發(fā)效率的另外兩個手段是代碼生成和類庫引用。但代碼生成和類庫引用，都只解決了邏輯的分解能力，沒有提供集成能力，所以一般情況下需要提供框架集成，尤其代碼生成需要在系統(tǒng)的最外層，避免集成帶來的問題。

代碼生成也沒有那么壞，關(guān)鍵在于生成什么，如果是生成結(jié)構(gòu)性的代碼，由于往往不是最終的產(chǎn)物，就存在同步維護(hù)問題；同時這種代碼是大都可以用template完成的。

但如果生成的是功能性代碼，這類代碼是最終執(zhí)行代碼，那么通常就把用于設(shè)計的代碼看作是最終產(chǎn)物，最明顯的例子是DSL。

（二）核心問題

1. 領(lǐng)域化

領(lǐng)域化，即領(lǐng)域建模。通常而言，領(lǐng)域模型設(shè)計中，模塊分解，抽象分層和職責(zé)分層都是重要手段。問題域為：流程，領(lǐng)域模型和領(lǐng)域服務(wù)（包括規(guī)則）。

a. 對象的抽象分解和集成

b. 對象的依賴分解和集成（模塊內(nèi)和模塊外）

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

d. 進(jìn)程邊界：用戶請求重定向，以及業(yè)務(wù)數(shù)據(jù)持久化等。

對于中等項目來說，系統(tǒng)中應(yīng)該有50-100個領(lǐng)域?qū)ο蟠砹藰I(yè)務(wù)抽象；

2. 組件化

面向?qū)ο笳Z言本身沒有提供的組件級別的依賴關(guān)系集成能力。語言不提供，因為領(lǐng)域組件的粒度太大，超越了語言的范疇。但我們可以通過框架提供，在Java體系中，目前已經(jīng)有兩個較好的解決方案：OSGi（JSR291）和SCA。可以很好的解決組件服務(wù)依賴關(guān)系管理，包括熱替換。

同時另一個問題——邏輯分層的問題：如保險產(chǎn)品面臨的核心層，國家層以及公司層三個邏輯層次分解和集成能力。這點的解決方案可以通過OSGi + Spring來解決，包括了靜態(tài)差異性替換和動態(tài)差異性替換。

還有組件邊界保護(hù)問題，我們希望限制別的組件訪問本組件內(nèi)部實現(xiàn)，有兩種手段可以完成，1是提交/部署時，通過在代碼提交時的代碼檢查工具，或者發(fā)布時編譯工具完成；2是通過OSGi的邊界限制能力。

3. 產(chǎn)品化

A. 定制化支持

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

A. 基于接口（包括了靜態(tài)替換和動態(tài)替換）

1. 靜態(tài)替換是Override，在OSGi中只要停止原有服務(wù)，啟用新服務(wù)即可，而在Spring中更改相應(yīng)配置文件即可；

2. 動態(tài)替換，其實是指運行時Condition Service Locator，在OSGi中可以利用Extension Point（Plug-in）解決，而Spring中只要提供一個類似Service Locator就可以。

B. 基于繼承（或者靜態(tài)類）

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

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

3.加載時，開發(fā)一個新邏輯的同名類，但其加載路徑優(yōu)先于原有類；

B. 升級支持

主要是增量升級支持，以及有限的降級支持。同時要考慮到對于定制化產(chǎn)品的升級支持。

4. 平臺化

A.基礎(chǔ)設(shè)施

基礎(chǔ)設(shè)施包括：類庫和框架?；A(chǔ)設(shè)施可以自己開發(fā)，或者應(yīng)用第三方（開源商業(yè)）實現(xiàn)。

A1. 基礎(chǔ)設(shè)施的選型

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

A2. 基礎(chǔ)設(shè)施的集成

基礎(chǔ)設(shè)施獨立后，出現(xiàn)平臺化的發(fā)展趨勢，這個趨勢有兩個方向：通用化和專業(yè)化。通用化意味著基礎(chǔ)設(shè)施和應(yīng)用的距離加大，易用性減低；而專業(yè)化意味著適應(yīng)性的減少。這是一個矛盾體。在基礎(chǔ)設(shè)施選型后，再進(jìn)行一定集成工作，可以結(jié)合當(dāng)前情況，平衡易用性和適應(yīng)性；同時合適的集成也有助于隔離技術(shù)和業(yè)務(wù)兩個方面。

從維護(hù)升級角度看集成的合適性：對于沒有標(biāo)準(zhǔn)的，不要做不必要的封裝，封裝等于是建立一個標(biāo)準(zhǔn)，而這是不現(xiàn)實的；應(yīng)當(dāng)盡可能采用框架方式，屏蔽基礎(chǔ)設(shè)施對于應(yīng)用程序的侵入性。如果是標(biāo)準(zhǔn)，就更沒有必要封裝，畫蛇添足。

B.業(yè)務(wù)支持

B1. 基本原則和手段

基本原則是：應(yīng)用程序POJO化。減少技術(shù)對于業(yè)務(wù)侵入性。主要手段是：容器上下文；依賴注入；AOP技術(shù)；元數(shù)據(jù)支持；事件機(jī)制；開發(fā)工具和代碼生成；

依賴注入+AOP+元數(shù)據(jù)構(gòu)成了簡單對象(POJO)的支撐技術(shù)?；诖巳灰惑w的技術(shù)可以有效的隔離業(yè)務(wù)問題和技術(shù)問題，更為甚者它可以支撐簡單對象體系，每個對象做且只做一件事。

B2. 開發(fā)模式與最佳實踐

基礎(chǔ)平臺應(yīng)該提供業(yè)務(wù)相關(guān)的模式封裝。

B3. 關(guān)于元數(shù)據(jù)

元數(shù)據(jù)有多種：語言級別為Annotation(微軟.NET為Customer Attribute)；框架級別可以是XML文件或者其它配置文件。

元數(shù)據(jù)可以通過以下幾個視角觀察

1. 應(yīng)用層次：元數(shù)據(jù)代表了業(yè)務(wù)含義和技術(shù)含義；

2. 技術(shù)分析：文檔類型（開發(fā)管理型）；編譯類型（類加載型）；運行期行為。

3. 物理分析，包括Annotation和接口，XML文件，甚至是EL和類。

元數(shù)據(jù)系統(tǒng)的建立其實是代表了認(rèn)知過程。

以運行期的元數(shù)據(jù)為例，代表了系統(tǒng)通過反射獲取相關(guān)元數(shù)據(jù)來自適應(yīng)系統(tǒng)，其實際意義在于將軟件設(shè)計開發(fā)人員對于系統(tǒng)的認(rèn)知通過技術(shù)手段固化下來。

元數(shù)據(jù)系統(tǒng)的開發(fā)目的有兩個：

1. 業(yè)務(wù)應(yīng)用上，提供業(yè)務(wù)動態(tài)能力；

2. 技術(shù)應(yīng)用上，簡化開發(fā)減低成本；

這里面有一個誤區(qū)是：為了技術(shù)應(yīng)用而過分地開發(fā)元數(shù)據(jù)系統(tǒng)，而隨著業(yè)務(wù)的演化導(dǎo)致為技術(shù)應(yīng)用的元數(shù)據(jù)迅速被拋棄，導(dǎo)致投入的浪費。實踐中要避免。

（三）應(yīng)用問題

1.事務(wù)管理

A. 成熟的事務(wù)技術(shù)：如數(shù)據(jù)庫；

B. 合理的并發(fā)設(shè)計控制；

C. 完整的業(yè)務(wù)日志；這也是解決業(yè)務(wù)回退的主要手段；

D. 輔助的數(shù)據(jù)校驗?zāi)芰Γ?/span>

并發(fā)設(shè)計控制和完整的業(yè)務(wù)日志，是架構(gòu)設(shè)計中保障數(shù)據(jù)一致性主要著力點。并發(fā)設(shè)計控制，需要結(jié)合業(yè)務(wù)，通過悲觀鎖定來保障。

而業(yè)務(wù)日志的獲取則面臨著諸多困難，主要是業(yè)務(wù)事務(wù)和物理事務(wù)的不一致性（即一個業(yè)務(wù)事務(wù)可能橫跨多個物理事務(wù)，也可能一個物理事務(wù)包括多個業(yè)務(wù)事務(wù)）；業(yè)務(wù)日志控制層面有兩個：應(yīng)用系統(tǒng)或基礎(chǔ)設(shè)計；通過應(yīng)用系統(tǒng)編碼控制，則不可避免的提高了應(yīng)用系統(tǒng)開發(fā)和測試的成本；通過基礎(chǔ)設(shè)施控制，有助于減低成本，但提高基礎(chǔ)設(shè)施的設(shè)計成本；

2.并發(fā)處理

    分析業(yè)務(wù)所涉及的并發(fā)場景，制定相應(yīng)的原則和方法，并合理選用現(xiàn)有的并發(fā)處理框架，進(jìn)行一定程度的剪裁，通過框架支持和簡化這些原則和方法的實踐。

3.系統(tǒng)分解

基于應(yīng)用的層面的分解，有多個緯度，包括：業(yè)務(wù)抽象度，業(yè)務(wù)任務(wù)，業(yè)務(wù)產(chǎn)品線，以及業(yè)務(wù)領(lǐng)域等等。

4.集成能力

軟件開發(fā)的適應(yīng)性在于分解粒度的大小，而分解粒度大小取決于集成能力。

1）依賴管理

在技術(shù)的角度看，軟件系統(tǒng)是一個存在大量依賴關(guān)系的對象系統(tǒng)。其中包括了兩種依賴：

1.業(yè)務(wù)代碼的對象依賴；比如調(diào)用一個工廠類創(chuàng)建一個對象。

2.業(yè)務(wù)代碼的環(huán)境依賴；它可能依賴于一個Web環(huán)境（讀寫Request和Response流），數(shù)據(jù)庫系統(tǒng)（讀寫數(shù)據(jù)記錄），文件系統(tǒng)和網(wǎng)絡(luò)系統(tǒng)等。

不幸的事是這種代碼量占據(jù)了大量的開發(fā)工作。重復(fù)的開發(fā)工作（對象或者數(shù)據(jù)的依賴關(guān)系維護(hù)工作）減低了開發(fā)效率和系統(tǒng)適應(yīng)變化的能力。

而這樣復(fù)雜依賴關(guān)系也給軟件的測試帶來了相當(dāng)大的困難需要搭建足夠的依賴環(huán)境（如一臺Web服務(wù)器和數(shù)據(jù)庫服務(wù)器），甚至是硬調(diào)試。

于是就有了采用第三方代碼來完成依賴關(guān)系維護(hù)工作的思路，所謂的依賴注入。業(yè)務(wù)對象出現(xiàn)Spring等著名框架

動態(tài)代理技術(shù)則解決了提供支撐環(huán)境封裝的問題。比如提供網(wǎng)絡(luò)訪問能力(如RMI，URL和Web Services)，文件訪問能力(如xml、property文件讀寫)。

由于企業(yè)開發(fā)中數(shù)據(jù)庫技術(shù)的應(yīng)用不可避免，因而ORM框架的出現(xiàn)還有特別的意義，在它的支撐下，核心業(yè)務(wù)西可以嚴(yán)格區(qū)別領(lǐng)域邏輯和業(yè)務(wù)邏輯，而這在以前是做不到的。

AOP開發(fā)的出現(xiàn)解決了面向?qū)ο笙碌臋M向組織關(guān)系。從一定程度上看，AOP可以看作是另一種依賴關(guān)系，可以另外依賴注入來實現(xiàn)。當(dāng)然也可以采用編程實現(xiàn)。

2）數(shù)據(jù)對象

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

VO對象是為了集成而存在的；其意義是：1. 保護(hù)系統(tǒng)的信息邊界，提供一種結(jié)構(gòu)可以使其它系統(tǒng)或者組件通過編碼方式獲取系統(tǒng)內(nèi)信息的方式；2. 保護(hù)系統(tǒng)的事務(wù)邊界，領(lǐng)域?qū)ο蠹夹g(shù)上攜帶著持久化信息，通過VO可以屏蔽得以屏蔽。常見的VO對象存在于Web層和Domain層。

因此，VO對象的存在只是為了集成而存在，其是否存在的取決于兩個方面1. 集成的設(shè)計結(jié)構(gòu)；2. 框架的兩個能力——對象路徑訪問能力以及事務(wù)邊界管理。

Domain層VO對象，通常是用于不同領(lǐng)域組件間的交互，但隨著架構(gòu)的改進(jìn)，集成代碼獨立存在而不再嵌入到組件內(nèi)部，組件的邊界問題保護(hù)不復(fù)存在；更進(jìn)一步的是，框架提供自動化的接口適配映射能力的增強(qiáng)。因而VO對象失去存在的意義。

Web層VO對象，以SWF為例，早在SWF 1.x時代，框架就提供了豐富的對象路徑訪問能力，但其Web交互是典型的MVC2方式，事務(wù)邊界在view的render前關(guān)閉，因而導(dǎo)致需要特定的VO對象來避免持久化信息問題；而SWF 2.x時代，view的render是在事務(wù)邊界內(nèi)，VO不再需要。

系統(tǒng)設(shè)計是一種結(jié)構(gòu)化過程，邏輯和數(shù)據(jù)被分解和集成到系統(tǒng)的各個部分；在運行期，真正重要的是結(jié)構(gòu)化路徑訪問能力，換句話說重要的是結(jié)構(gòu)化后的路徑，而實際用何種數(shù)據(jù)結(jié)構(gòu)其實不重要。

可以使用數(shù)據(jù)樹Data Tree形式，提供扁平化的數(shù)據(jù)訪問能力，是一種較好的開發(fā)方式，極大的提升了開發(fā)效率。Spring Web Flow以及其它框架廣泛的運用EL提供統(tǒng)一的表達(dá)式訪問數(shù)據(jù)，也大大降低了開發(fā)成本。

3）事件機(jī)制

事件機(jī)制應(yīng)用非常廣泛，是很重要的集成手段。事件機(jī)制的優(yōu)勢在于其提供了松散耦合而帶來的擴(kuò)展能力?；趥鹘y(tǒng)事件模式，可以擴(kuò)展提供同步/異步，事務(wù)隔離等額外控制能力。

4）組件設(shè)計

一個組件包括了API和SPI，其中API是用于客戶方編程，SPI用于服務(wù)方編程（屬于框架回調(diào)）。無論是API和SPI都是該組件所有，體現(xiàn)了一個組件自身的完備性。其與其它組件依賴通過集成模塊完成，依賴解藕。

組件的設(shè)計還分層次，上層組件的邏輯依賴下層組件，上層組件直接訪問下層組件的服務(wù)和模型，保持單向依賴有助于降低開發(fā)和維護(hù)成本。而平級組件，由于組件的替換可能性大，因而保障組件邊界完整性尤為重要。

接口的實現(xiàn)是關(guān)鍵。面臨的問題是，在開發(fā)初期需求不確定和經(jīng)驗不足的情況下，接口的設(shè)計不盡合理，導(dǎo)致需求變動后，所進(jìn)行的修改將影響三個方面，接口、接口實現(xiàn)對象和測試用例。工作量將可能很大。特別是在并行開發(fā)過程中，一個通訊接口的變化將可能引起很大連鎖反應(yīng)，導(dǎo)致其他成員不得不停下手上的工作。

因而在實際開發(fā)中需要做個權(quán)衡。不同模塊的通訊接口應(yīng)該由團(tuán)隊成員共同負(fù)責(zé)，一旦接口變化，接口實現(xiàn)成員應(yīng)該提供相應(yīng)的假實現(xiàn)。而模塊內(nèi)部可以由開發(fā)人員自行設(shè)計，可以在初期不提供接口和簡單的測試用例，在項目具有一定穩(wěn)定性后，利用重構(gòu)實現(xiàn)接口和完整的測試用例。

有效定位系統(tǒng)錯誤。尤其在組件化和分層化，以及其它開發(fā)手段混合運用情況下。例如，A，B，C。由于C引起的錯誤導(dǎo)致A錯誤是很難查的。代價很高。

5）膠水層

膠水層代碼屬于集成范疇。它是系統(tǒng)開發(fā)中不可避免的。膠水層代碼的存在增加了設(shè)計、開發(fā)和測試的成本。因盡量減少膠水層代碼的人工開發(fā)。

膠水層代碼有兩種類型：一是適配器，二是開發(fā)模式。

適配器對于集成來說并不陌生。適配器從用途上分可以分為兩種：業(yè)務(wù)適配和技術(shù)適配。業(yè)務(wù)適配是指處理應(yīng)用程序接口的適配調(diào)用，消除應(yīng)用程序的耦合度；技術(shù)適配是指處理應(yīng)用程序和技術(shù)框架上，消除技術(shù)框架的耦合度。

開發(fā)模式是指基礎(chǔ)平臺對于應(yīng)用開發(fā)的支持減少無效代碼，例如采用ORM系統(tǒng)（如Hibernate）以及有狀態(tài)的Web層框架（如Seam和SWF）可以有效減少應(yīng)用系統(tǒng)處理數(shù)據(jù)（對象）狀態(tài)；以及各種元數(shù)據(jù)的識別和增強(qiáng)。

6）集成階段

根據(jù)階段分為：設(shè)計時, 編譯（加載）時和運行時。設(shè)計時是由人工編碼，通常就是一些特定業(yè)務(wù)代碼，完成集成工作；編譯時集成工作通常指配置文件，由程序員提供，但不需要編碼工作；而運行時指通過指定元數(shù)據(jù)，由框架運行時解析；

5.部署方式

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

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

1.       前后端分離方案

傳統(tǒng)EJB方案就是此種。面臨的問題和風(fēng)險：

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

包括：分布式調(diào)用；分布式事務(wù)管理；開發(fā)模式（即上下文的傳遞）。

b)         運行成本，即分布式數(shù)據(jù)傳輸性能問題；

2.       采用Portal或類似技術(shù)

（四）設(shè)計問題

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

面向?qū)ο筇峁└鞣N關(guān)系的表達(dá)能力：關(guān)聯(lián)，依賴，集成，組合等；類似于數(shù)據(jù)庫表關(guān)系，但是更強(qiáng)烈。在設(shè)計時需要注意表現(xiàn)。

新的開發(fā)方式，應(yīng)該可以通過代碼記錄分析設(shè)計的成果，形成系統(tǒng)中一個穩(wěn)定的可發(fā)展的抽象層次代碼，而開發(fā)實現(xiàn)則繼承或者適配該抽象層次，最終保證系統(tǒng)可運行性。

這樣知識層面的分析設(shè)計可以有效貫徹發(fā)展，而操作層面的開發(fā)實現(xiàn)可以關(guān)注于實現(xiàn)過程的工具和手段。這樣就可以確保設(shè)計是做正確的事，而開發(fā)過程提供各種框架工具則把事做更有效率。

六、架構(gòu)的展示

1.兩個要素

架構(gòu)要展示的兩個基本要素是：業(yè)務(wù)和技術(shù)組件。而業(yè)務(wù)又可分為組件和功能兩個層次，技術(shù)又可分為基礎(chǔ)平臺與組件所需提供工件兩個部分。

后續(xù)所有展示都圍繞此二要素。

2.核心視圖

由RUP貢獻(xiàn)的四個視圖是架構(gòu)展示的核心視圖。

邏輯視圖（靜態(tài)類圖）

關(guān)注功能，不僅包括用戶可見的功能，還包括為實現(xiàn)用戶功能而必須提供的"輔助功能模塊"；它們可能是邏輯層、功能模塊等。

應(yīng)映射為業(yè)務(wù)組件、功能包以及技術(shù)工件（分層），以及它們之間關(guān)聯(lián)依賴關(guān)系；

開發(fā)視圖（靜態(tài)類圖）

關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件。

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

應(yīng)映射為具體的SDK和框架等，以及關(guān)聯(lián)依賴關(guān)系；注：開發(fā)視圖應(yīng)盡可能和邏輯視圖一一對應(yīng)；

處理視圖（動態(tài)類圖）

關(guān)注進(jìn)程、線程、對象等運行時概念，以及相關(guān)的并發(fā)、同步、通信等問題。

處理視圖和開發(fā)視圖的關(guān)系：開發(fā)視圖一般偏重程序包在編譯時期的靜態(tài)依賴關(guān)系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進(jìn)程，處理視圖比較關(guān)注的正是這些運行時單元的交互問題。

可映射為狀態(tài)圖和活動圖（高層和詳細(xì)）；

物理視圖（部署視圖）

關(guān)注"目標(biāo)程序及其依賴的運行庫和系統(tǒng)軟件"最終如何安裝或部署到物理機(jī)器，以及如何部署機(jī)器和網(wǎng)絡(luò)來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。

物理視圖和處理視圖的關(guān)系：處理視圖特別關(guān)注目標(biāo)程序的動態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個IT系統(tǒng)相互影響的架構(gòu)視圖。

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

3.擴(kuò)展視圖

在核心視圖，針對于不同受眾，還需要提供三個擴(kuò)展視圖。

非功能視圖

展示非功能性指標(biāo)的支持能力。通常針對于技術(shù)人員。

基礎(chǔ)設(shè)施視圖

展示架構(gòu)所采用基礎(chǔ)設(shè)施，以及它們之間的關(guān)系。通常針對于技術(shù)人員。

數(shù)據(jù)視圖

關(guān)注于數(shù)據(jù)組織和存儲形式。通常針對于DBA，或者需對數(shù)據(jù)進(jìn)行定期維護(hù)的用戶。

4.原則和約束

架構(gòu)因明確說明本架構(gòu)采用原則、方法論以及相關(guān)約束。

5.技術(shù)選型分析

由于架構(gòu)涉及眾多底層技術(shù)，也應(yīng)給出相應(yīng)的選型分析。