3.1 軟件架構中需要關注的一些方面

任何一種軟件架構，都含有多個方面，而且其中某些方面可能還會變得令人畏懼，（從架構的角度來看，）這通常都是因為過分關注細節而導致的。要想避免這種情況，就必須選出一些合適的觀察面，使得這些方面不僅能夠涵蓋解決方案中的諸多側面，而且能夠令我們可以與利益相關者進行有效的溝通。此外，對觀察面所進行的選擇，還取決于當前這個系統的固有復雜程度。當然，架構師的個人喜好，也是一個因素。

前面說過，本書的主題是怎樣恰到好處地把握住架構工作，因此，筆者只會專門講解那些自己認為對系統的成功會起到必要和充分作用的架構工作，即便面對特別復雜的系統，我們也依然應該把重點放在這些工作上。

本書要講解下列幾個方面：

系統環境（System Context）—描述IT系統（通常表示為黑盒）與外界實體（外界系統及終端用戶）之間的交互情況，并確定系統與外部實體之間的信息流與控制流。它用來闡明、確認并捕獲本系統的運作環境。這些外圍系統及其接口，以及信息流與控制流的性質，都是我們在為本架構中的技術工件擬定下游規范時所應考慮的問題。

架構概述（Architecture Overview）—通過簡潔而清晰的示意圖，演示軟件架構中的主要概念元素，以及這些元素之間的關系。架構概述圖可以在不同的層級上繪制，也就是說，我們可以繪制企業級的視圖、IT系統級的視圖以及分層的架構視圖。這些視圖有助于展示出能夠為IT系統提供支持的架構工件。這些工件都是宏觀的符號，有待以功能模型和操作模型的形式做進一步的細化。此外，總覽圖還描繪了企業在構建IT系統（尤其是當前這個IT系統）時所遵循的戰略方向。

架構決策（Architecture Decision）—提供一個堅固的工件，以捕獲架構方面的相關決策。這些決策通常是圍繞這幾個問題而展開的：確定系統的結構，為滿足集成方面的需求而確定中間件，把系統的功能與架構中的每個組件（或架構中的每個構建塊，也就是ABB）對應起來，把各ABB安排到架構中的各層里，服從并遵守相關的標準，選定實現某個ABB或功能組件所用的技術等，除此之外，可能還有其他一些問題也需要做出決策。凡是對滿足架構中的業務目標、技術目標和工程目標比較重要的決策，都應該捕獲成架構決策。需要記錄的內容包括：問題的確定過程，對各種解決方案及其優缺點的評估過程，解決方案的選擇過程，選定某個方案時所依據的理由，以及對下游的設計和實現有所幫助的相關細節。

功能模型（Functional Model）—也稱為組件架構或組件模型。它用來描述、定義并捕獲軟件架構的分解方式，使得架構可以分解為多個IT子系統，每一個子系統都是一個邏輯群組，用來容納相關的軟件組件。這種工件會從軟件組件的角度來描述IT系統的結構，同時也會指出組件的職責、接口、靜態關系以及協同運作機制。這些組件需要按照該機制進行運作，以便使系統能夠具備預期的功能。此工件在迭代開發過程中，會經歷多個階段的細化（elaboration，精化）。

操作模型（Operational Model）—表示一個由計算機系統所構成的網絡，此網絡不僅會為某些非功能的系統需求（例如性能、可擴展性以及容錯能力等）提供支持，而且還能夠運行中間件、系統軟件以及應用軟件組件。此外，它還定義了計算機系統的網絡拓撲結構及相互連接情況。與功能模型一樣，操作模型在迭代開發過程中，也要經歷多個階段的迭代和細化。

集成模式（Integration Pattern，整合模式）—指的是一系列最為常見的可復用模式，這些模式專門用來對某些技術進行簡化和整理，使得當前系統能夠更加流暢地用這些技術與其他相關應用程序及系統進行連接與溝通。它可能會利用中介（mediation）、路由（routing）、轉換（transformation）、事件探測（event detection）、信息代理（message brokering）及服務調用（service invocation）等架構模式。

基礎設施架構（Infrastructure Architecture）—專注于基礎設施的開發工作，這些設施包括服務器、存儲設備、硬件、工作站、非應用程序型軟件以及實體設備等，它們用來為應用程序的開發、測試、部署、管理及維護工作提供支持。

大家一定要意識到：只要系統能夠適當地運轉，它就具備可用性。然而對于基礎設施方面來說，為了保持系統的這種可用性，我們必須把系統與用戶交互時的延遲時間和周轉時間（turnaround time）處理好，同時還要保證系統能夠具備適當的運算能力，以支持功能和非功能方面的需求。