《實用軟體架構：從系統環境到軟體部署 》——2.3 為什麼需要做軟體架構

本節書摘來自華章出版社《實用軟體架構：從系統環境到軟體部署》一書中的第2章，第2.3節，作者：[印]蒂拉克·米特拉（tilak mitra）著，愛飛翔　譯，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

<b>2.3　為什麼需要做軟體架構</b>

筆者是這樣一種人：除非我能确信自己真的需要去做某件事，并且了解它的重要性和價值，否則，我就很難全身心地投入其中。如果讀者也是這樣的人，而且你也想了解軟體架構的價值到底展現在哪裡，那麼就請繼續往下看吧。

本節将會給出一些理據，來說明軟體架構的重要意義。筆者之是以會極其熱衷地從事架構工作，正是由于這些理據能夠使我感到信服。

<b>2.3.1　把架構視為交流工具</b>

軟體架構是一張藍圖，it系統的設計、建構、部署、維護及管理，都要依照這張藍圖來進行。很多利益相關者都想對系統架構有一個良好的了解，然而單單從某一個視角來切入系統架構，是無法滿足所有人的。由于不同的利益相關者可能有着不同的需求與期望，是以，我們需要從多個角度來觀察架構。

為了把架構的實質内容準确地告知利益相關者，我們需要從各種不同的角度來進行溝通。比如，在與業務的發起方進行溝通時，架構師一定要采用與業務有關的說法來交談，例如要清晰地闡明該架構是怎樣解決業務需求的。在與業務方面的利益相關者進行溝通時，架構師也要使他們确信：這個架構并不是那種原來已經嘗試過但卻沒能取得成功的架構。架構師所選取的表現形式，應該要能展示出這套架構為了滿足某些宏觀的業務用例，是怎樣把一個或多個abb的能力結合起來的。這種表現形式（也就是觀察點，本章稍後将會詳述它）及展示形式，同時還要凸顯出架構藍圖的價值，并把這套藍圖視為整個系統得以設計和建構的基礎。架構藍圖的這種效用，按照業務術語來說，就叫做價值驅動力（value driver），我們最終需要依靠這種驅動力，來確定該架構能夠獲得足夠的投資，這些資金，至少要能夠使系統得以部署并穩定地進行運作。

架構的表現形式有很多種，技術團隊可以根據自身所處的技術領域選用适當的形式。比如：

應用程式架構師（application architect）需要了解系統的應用程式架構，需要專注于功能元件、元件的結構以及元件之間的依賴關系，也就是說，他們需要從功能架構的視角進行觀察。

基礎設施架構師（infrastructure architect）可能對伺服器的拓撲結構、伺服器之間的網絡連接配接狀況以及伺服器中各個功能元件的排布狀況感興趣（然而他們所關注的問題并不局限于這些），也就是說，他們需要從操作架構的視角進行觀察。

業務流程的擁有者（business process owner）當然要了解架構所支援或加以自動化的各種業務流程，這些流程是通過對系統所提供的特性與功能進行編排而實作出來的，其實作方式，通常是把一個或多個業務元件所具備的各種能力加以協調。業務流程的擁有者所感興趣的這些問題，可以用靜态的業務元件視圖及動态的業務流程視圖來進行展示，也就是說，他們需要從業務架構的角度進行觀察。

針對架構問題進行有效的溝通，可以促使我們就正确的解決方案與方法展開有益的讨論，并對各種方案進行分析及權衡，以做出相應的決策。這不僅可以確定利益相關者的意見受到關注，而且還能夠提升架構本身的品質。

我們要用各種方式與多位利益相關者進行溝通，使他們都能夠明白架構的價值，并且了解價值中與自己有關的那個方面，同時還要使他們積極參與架構的演化過程，這對架構是否能夠适當地延續下去，會起到很關鍵的作用。

<b>2.3.2　對項目規劃施加影響力</b>

我們在前面講過，宏觀層面上的軟體架構，可以由一系列abb以及這些abb之間的互相關系和依賴情況所确定。我們也說過，abb還可以繼續向下分解為一系列元件，這些元件之間，依然有着互相依賴的關系。在一般的軟體開發過程中，我們通常要根據很多參數來排列系統的各項功能，以決定其優先順序，這些參數包括：是否需要立刻展示系統的特性、是否需要先解決棘手的問題（用軟體架構的術語來說，這些問題通常稱為架構上重要的用例），以及季度的資本支出預算等。無論具體原因是什麼，我們一般都需要對系統中某些特性之間的優先順序進行規劃。對軟體元件的實作進行規劃時，可以參照abb之間的依賴情況來進行，如圖2-2所示。

以圖2-2為例，元件c2群組件c3，都依賴于元件c1的功能，而元件c2與元件c3之間，則是互相獨立的，于是，架構師就可以利用這一現象來對項目的規劃過程施加影響。比如，如果有足夠的資源（也就是有足夠多的設計師），那麼架構師就可以并行地規劃c1、c2和c3的設計工作，此外，（在有足夠資源的前提下）也可以先把c1實作出來，然後再去并行地實作c2和c3。要想做好項目規劃工作，就一定要對架構及其元件有适當的了解。架構師通常是項目經理的好搭檔，在進行項目規劃時，尤其如此。

架構師可以給項目的規劃過程提供幫助，但是另一方面，項目規劃團隊通常也想更多地參與到架構事務中。架構元件的複雜程度，會對時間和資源（也就是專業技能和各種水準的專業知識）的指派和配置設定造成影響。

如果利益相關者不能夠徹底地了解架構，那麼對于具有一定規模的系統來說，其後續的設計、實作、測試計劃以及部署等階段，就會遇到巨大的困難。

<b>2.3.3　關注非功能方面的能力</b>

對軟體系統在非功能方面的能力加以關注，是軟體架構的一項關鍵職責。我們通常都說：如果在進行系統架構工作時沒有對非功能型需求（nonfunctional requirement，nfr）給予足夠重視，那麼系統通常就會出現故障或發生崩潰，事實也确實如此。

在系統的非功能型需求中，可擴充性（extensibility）、可伸縮性（scalability）、可維護性，以及性能和安全程度，是其中比較重要的幾個需求。nfr的特殊之處在于，它們本身雖然未必是元件實體，但是卻需要架構中能夠有一個或多個功能元件對其進行特别的關照。就這一點來說，架構中的非功能型需求，可以對這種功能元件的屬性施加影響，并促使我們去增強其屬性。考慮這樣一個用例：系統需要把響應時間控制在1秒以内。系統架構師決定把c1、c2和c3這三個元件結合起來，以實作該用例。在這種情況下，元件的特性所具備的本質特點及複雜程度，就規定了每個元件必須要在多長時間内完成其職責，例如c1可能必須在300毫秒内完成，c2可能必須在500毫秒内完成，c3可能必須在200毫秒内完成。由此或許可以發現一些線索，使我們能夠看出為了展現、支援或遵照某些特性，還需要給abb添加哪些屬性。

要想做出設計精良、考慮周到的架構，就應該對系統中那些非功能型需求給予适當的關注。在軟體開發的生命期中，這些需求應該放在架構定義階段來考慮，而不能等架構确定好之後再去考慮。

從技術角度來看，如果我們在進行系統架構時，能夠适當地關注并考慮非功能方面的需求，那麼系統的故障風險就會大幅度降低。

<b>2.3.4　與設計團隊和實作團隊做出約定</b>

軟體架構中的一項重要内容，就是确立工作原則、指導方針、工作标準以及架構模式，架構師要對這方面的問題進行記錄，并與設計團隊和實作團隊進行溝通。

在進行溝通時，架構師不僅要談論架構中的abb以及各abb之間的接口和依賴關系，而且還要談到工作原則、指導方針、工作标準以及架構模式等問題，這些問題合起來可以構成一套限制規則及邊界條件，進而為系統架構和系統實作工作的确立與開發劃定出一個範圍。有了這樣的限制規則，設計團隊和實作團隊就可以避免一些毫無必要的創新活動，他們會把注意力放在如何遵循這些限制上，而不會想着去打破它們。

在溝通過程中，架構師應該確定設計團隊和實作團隊能夠意識到這些限制的重要性，并且使他們意識到自己不應該去違背架構原則與系統約定。在特殊情況下，如果确實存在強有力的理由，那麼可以容許某些違背限制的做法，但這隻能是特例。

<b>2.3.5　為影響力分析提供支援</b>

有一種狀況對大家來說應該不會太過陌生，那就是由于新需求失控而導緻的範圍蔓延（scope creep）。為了防止出現這種狀況，項目經理需要對新需求進行了解和評估，以确定其對目前項目的工作日程所造成的影響。

如果項目經理是個經驗比較豐富的人，那麼就會在第一時間去詢問項目的主架構師，并且請該架構師進行必要的影響力分析（impact analysis）。

前面我們說過，軟體架構可以确定架構中的各個abb，也可以确定這些abb之間的互相關系、依賴情況以及互動情況。是以，架構師可以對将要實作的新用例進行某種分析，以判斷出架構中有哪些元件必須為此做出修改。架構師還可以根據新用例所需的資訊交換和資料交換等操作，判斷出架構中各元件之間的依賴關系是否也要進行修改。需要進行修改的元件數量、修改的幅度以及實作新用例所需的額外資料或資料源，都與新用例對項目的工作日程所造成的影響有着直接的關系。我們還可以進行更加深入的分析，以判斷出這些修改對項目所造成的影響，以及項目成本和相關風險的提升程度。在考慮成本問題時，元件的特征是相當關鍵的名額，因為元件的設計成本、實作成本以及後續的維護和增強工作所需的成本，在很大程度上都與元件的特征有關。

筆者剛才提出了5項理由，用以證明軟體架構的重要性。讀者或許還能提出更多的理由，以論證其重要性。盡管如此，但筆者還是決定就此打住，因為我覺得上述理由已經足以令自己确信其重要性了，而且這樣做也與本書的主題相一緻。在本書中，如果筆者感覺對某個話題已經講解得恰到好處了，那麼就會繼續講下一個重要的話題。筆者的目标，就是要通過這本書來分享自己的經驗，告訴大家怎樣才能把軟體架構中的各項原則運用得剛剛好，讀者可以把這個水準當成參考基線或參照系，并按照自己的需求來進行調整。