目标
程式架構基礎
标準關鍵程式建構術語和原則
促使現代架構形成的關鍵因素
概要
定義程式架構就是定義結構化的解決方案的過程，這個解決方案可以滿足所有的技術和操作的需求，以及最佳化的一般品質特性，如性能，安全和可管理性。
這包括廣泛因素的一系列的決策，每個決策都考慮到了對品質，性能，可維護性和程式的成功。下面我們就展開對這一過程的描述，并使用其中包含的資訊，你可以建構一個包含所有要點的架構。并可以使這個架構部署在你選擇的基礎之上，并且符合所有的原始的目标和需求。本章是實踐性的程式架構的基礎。首先從高層介紹架構和設計，之後詳細介紹具體的架構和設計。提示符和以上采用同樣方式。最後，本章會給出關鍵術語和原則。了解這些會幫助你從本指南中獲得最大的收益，并成為一個更好的架構師。通過學習本章，你會從整體角度了解結束和架構及設計，主要的你必須考慮的因素和你在設計架構是可以使用的主要方法。
這會幫助你了解一些架構和程式風格，品質特性和交叉相關的概念以及分析和展示架構。
什麼是軟體架構？
軟體架構一般被定義為一個系統的機構和各種結構的集合。
一些我們熟知的工業專家在架構相關決策的基礎上擴充了這個定義。
kruchten, booch, bittner, 和 reitman對架構的定義
根據工作的經驗philippe kruchten, grady booch, kurt bittner和rich reitman繼承并提煉了架構的定義。他們的定義是：“軟體架構包括了一些列的顯著的軟體系統組織的決策，包括：
ü 選擇結構元素和他們組成系統的接口。
ü 明确這些元素之間的協同行為
ü 把這些結構的和行為的元素組成一個更大的子系統
ü 指導這種組織的架構風格
軟體架構同時包括功能性、可用性、可靠性、性能、複用性、廣泛性以及經濟和技術限制、權衡和美觀等相關問題。”
fowler 給出的架構定義
• 從最高層分解系統。
• 決策很難修改。
• 一個系統中存在多個架構。
• 架構會影響一個系統的生命期。
• 最後，架構按照系統的各個總要部分分解。
bass, clements, kazman對架構的定義
在《軟體架構實踐（第二版）》中bass, clements, 和 kazman這樣定義軟體架構：
“一個軟體或者是一個計算系統的架構就是這個系統的結構或者結構的集合，包括軟體的各種元素，這些元素的外部可見的屬性和他們之間的關系。架構主要是關于公共接口的，這些元素的内部細節—需要在内部實作的細節與架構無關。”
我們為什麼需要架構設計？
想其他的複雜結構一樣，軟體必須建立在一個穩定的基礎之上。沒有考慮到關鍵的用例，沒有處理好常見的問題，或者沒有對長期的關鍵決策做好評估，會導緻一個應用的失敗。先待工具和平台會幫助你簡化建立應用的難度，但是他們不會在需求之上建立你的應用程式。不好的架構導緻的風險包括不穩定，不支援業務需求，甚至軟體部署到工作環境時無法工作。考慮軟體架構時，從高層考慮一下問題：
• 軟體如何部署到生産環境？
• 使用者會如何使用軟體？
• 品質需求有哪些，比如安全，性能，并發，國際化以及配置？
架構和設計
目前或者在你部署了你的軟體後，會影響到你的架構的趨勢是什麼？martin fowler說道：“專家一級的開發人員對于項目有個共同的了解。這個共同的了解叫做‘架構’。這個了解包括如何把系統分塊以及這些不同的子產品如何通過接口互相作用。這些子產品通常又由更小的子產品組成，但是架構隻包括這些可以呗所有開發人員了解的子產品以及他們之間的接口。”。是以結構主要集中在如何分解出子產品和他們之間的接口。選擇資料機構和算法實作已經不是架構了。不要用硬性快速的法則去區分架構和設計的差別，把他們兩者結合起來才更有意義。在某些場合下，決策本質上來說更接近與架構。在其他情況下，決策又更接近于設計，并幫助你實作架構。
使用者，業務和系統目标
系統架構的建立需要考慮到使用者，系統和業務目标。每個領域都需要列出關鍵場景，重要的品質屬性（比如，可維護性），關鍵客戶要求實作的功能。如果可以，開發時，考慮每個領域中的成功的度量标準。
圖1
在每個領域中都會有權衡，并且平衡點也必須找到。比如，反應時間可能是一個使用者體驗方面的要求但是系統管理者卻不願意投資到硬體上。而平衡點可能隻是滿足使用者80%反應時間要求。
架構的目标
通過了解用例，軟體架構可以建立業務需求和技術需求之間的橋梁，并在軟體中實作用例。架構的目的就是為了辨識出對軟體的結構有重大影響的需求。好的架構可以有效的降低業務的變化對解決方案的影響。一個好的設計可以非常靈活的适應由于時間引起的硬體和軟體技術的變化，以及使用者場景和需求的變化。一個架構師必須考慮設計決策，品質屬性（比如：性能和安全）固有平衡，使用者、系統和業務需求等對整體的影響。
架構應該包括的一下的内容：
• 找出系統的結構但是隐藏實作的細節。
• 實作全部的場景用例。
• 列出所有的利益相關者關注的問題。
•
功能和品質需求全都處理。任意的架構，實作架構的方式，都必須列出全部的關鍵決策。至少你必須确定你要建立的架構的類型，建立架構的風格并且處理這些問題的交叉部分。通過這個指南，我們會通過基本的架構來列出在你的架構中需要考慮的各個方面。基本架構在下圖中。
圖2
此外，對于基本架構來說，你可以用下列的方式來幫助你定義你自己的架構。第一步是你的要建立的應用的類型。接着，你必須了解你的軟體如何部署。一旦你明白了你應用的類型以及該軟體如何部署，你就可以開始用你認為合适的風格和技術來建立你的軟體。最終，你需要把考慮品質屬性和交叉點容納到你的設計中。
應用類型
作為設計群組織軟體架構過程的一部分，選擇正确的應用類型極為關鍵。這取決于需求和基礎結構的限制。本指南包括了一下的應用類型：
l 移動裝置的移動應用
l 主要運作在客戶機上的富用戶端應用
l 部署在internet上的支援豐富的ui和媒體的ria應用
部署政策
當你設計架構時，你必須考慮到共同的方針和處理過程，以及你要部署你軟體的基礎。目标環境是靈活的還是不變的，你的軟體必須考慮到在目标環境中存在的限制。你的應用程式必須同時考慮到品質屬性比如安全和性能以及可維護性。有時你必須因為網絡技術和協定做出必要的權衡。盡早在設計階段分辨出需求和基礎結構的限制和需求。這會幫助你選擇一個正确的部署技術，幫助你盡早解決軟體和基礎架構之間的沖突。
架構風格
一種架構風格就是一些列的組成該風格的原則。每種風格都定義了一系列的規則，這些規則指明了你可以用于組成系統的元件，在軟體元件之間關系，各個元件組織到一起的限制，以及他們組織到一起的方式。架構風格的例子是客戶機/伺服器，基于元件的，分層架構，消息總線，mvc，三層/n層，面向對象，以及面向服務的架構（soa）。很多的因素會影響你對架構風格的選擇。這些因素包括你所在開發機關的設計和實作的能力，開發人員的經驗和能力，以及可以獲得的架構限制和部署場景。
合适的技術
當為您的軟體選擇技術的時候，要考慮的關鍵因素是你所要開發的軟體的類型，和軟體部署技術以及架構風格。技術的選擇也會受到代發機關政策，基礎架構限制，技術資源等的影響。你必須比較在你的需求的基礎上考慮你選擇的技術，并且在做出任何的決定之前考慮其他的因素。
品質屬性可以把你的思考集中在幾個設計中必須解決的關鍵的問題上。在你的需求的基礎之上，你可能要考慮在本指南中列出的全部的品質屬性，或者這些品質屬性的一個子集。比如，每個軟體都必須考慮安全和性能，但不是每個設計都需要考慮互操作性或者可更新性。首先了解你的需求和部署場景，這樣哪些品質屬性對你的設計很重要。記住品質屬性會出現沖突。比如，安全性需要對性能和可用性做出權衡。在做安全性方面的設計時，分析并了解關鍵的權衡，就會避免邊緣作用對軟體産生顯著的影響。在品質屬性設計中可以考慮一下的指導：
l 品質是系統級屬性，是和功能分離的。
l 從技術的角度講，品質屬性的實作與否或實作如何可以區分一個軟體的好壞。
l 有兩種品質屬性：一種是在運作是度量的，一種隻能通過審查來度量。
l 分析品質屬性之間的權衡。
當你考慮品質屬性時，有幾個問題你需要考慮：
什麼是你軟體要求的關鍵的品質屬性？在設計的過程中找出他們。
客戶的接手标準是什麼，這表明了你是否符合需求。
關注交叉點
交叉點代表了軟設計中與某一層無關的關鍵域。比如，你可能想在展示層和資料通路層緩存資料。你也需要設計一個在每一層都工作的異常處理架構。另外，你還設計每一層都可以使用的日志系統以及設計一個在不同層之間通訊的功能。權限管理也存在于不同的層次之間，是以你必須決定如何在系統中傳遞一個認證并使持有這個認證的使用者可以通路特定的系統資源。一下清單描述了架構中必須考慮的交叉點：
身份認證：決定如何驗證使用者并在不同層之間傳遞認證的身份。
權限：在每一層和信任授權之間的授權正确。
緩存：确定什麼是需要緩存的，緩存位置以改善軟體的性能和響應時間。設計緩
存時一定要考慮到網頁和網絡應用的問題。
通訊：選擇和是網絡技術，減少網絡調用并防止敏感資料在網絡中傳輸。
異常管理：在邊界捕獲異常。不再終端使用者錢顯示敏感資訊。
規範應用程式和日志：規範全部的業務和系統關鍵事件，并詳細記錄日志以便重建事件。不要記錄敏感資訊。
靈活架構
靈活架構假設軟體的設計會随着時間的改變兒改變，并且你不知道為整個系統設計架構需要知道的所有資訊。你的設計，總的來說，會在實施階段獲得了更多的資訊後，或是在實際環境中測試過後加以改進。由于在設計的開始階段無法全面的了解需求，而不斷在頭腦中改進架構。用靈活的方法設計架構時，需要考慮一下問題：
在架構中，如果你出錯了給整個系統帶來最大風險的基本子產品有那些。
架構中的那些部分是最容易改變的，或者說那部分的設計退後之後對系統的影響最小？
你的關鍵假設是什麼，如何測試他們？
何種情況會使你重新考慮你的設計？
不要過分設計，不要做無法驗證的假設。相反的，保持對未來的變化開放的想法，而不是把自己逼到牆角。有些方面，如果重新設計會給你帶來很高成本的話，是你在設計的初期就必須确定好的，盡快确認這些域，并認真分析他們。
靈活架構包括一些關鍵的原則：
模組化适應改變：任何地點隻要可能，設計你的軟體，以使之可以适應新的需求和
挑戰。
模組化分析、減低風險：給風險模組化以了解風險和易出問題的地方。
模組化和試圖隻是溝通和協調的工具：設計原則行業設計變更的溝通是靈活設計的
關鍵所在。使用者模組化和其他的可視化手段可以使得溝通更加有效并可以使得
團隊針對設計的變更做出迅速的應對。
确認關鍵模組化決策：用本指導的架構來了解工程決策，區分出經常容易出錯的地方。最後可以第一時間找出這些關鍵決策，以使設計更加靈活和更容易适應變化。
增量和疊代架構方式
靈活架構通過增量和疊代的方式達到改進的目的。就是不要在第一次就把搜有的事情都作對。盡可能的設計，之後在需求和假設的基礎上驗證你的設計。疊代的在你的設計中添加細節，以使你在第一次就在重要問題上做出正确的決策，之後關注細節。一個常犯的錯誤就是過早的進入到了細節問題，并在錯誤的假設上做出錯誤的決策，或者無法評價架構是否有效。保證架構的基本方面是正确的，并測試這個架構，同時考慮一下問題：
• 在這個架構中我做了什麼樣的假設？
• 這個架構能滿足什麼樣的顯式或隐性的需求？
• 這樣架構設計方式會有什麼樣的風險？
• 通過何種方法應對關鍵的危機？
• 以何種方式改進架構的基本設計或最近一個版本的架構？
基本架構和待測架構
一個基本架構就是對現存系統的描述—也就是你系統目前的結構。如果是一個全新的架構，那麼你的基本架構就是這個架構設計的最高層描述，待測架構也将從這裡産生。一個待測架構包括應用類型，部署架構，架構風格，技術選擇，品質屬性和交叉點。
architectural spikes
an architectural spike是一個軟體的每個小塊的端到端的測試。目的就是減低風險并測試潛在路徑。隻要你評價你的架構，你就會用這些spike來發現不同的場景，但這不會對軟體現有的設計産生任何影響。an architectural spike可以得出一個待測架構，這個待測架構可以在基礎架構的基礎上進行測試。如果一個待測架構是一個改進，那麼它就可以作為下一個待測架構的基礎架構。這樣的疊代和增量方式使你可以在第一時間擺脫較大的風險。用疊代的方式得出架構，并用架構測試證明每個基本架構都是一個改進。考慮下面的問題，以幫助你測試一個新的待測架構：
• 這個架構會導緻新的風險嗎？
• 這個架構會降低已知的風險嗎？
• 這個架構滿足其他的新增的需求嗎？
• 這個架構支援架構級的用例嗎？
• 這個架構列出了品質屬性了嗎？
• 這個架構列出了增加的交叉點了嗎？
架構級的用例
架構級用例的符合以下标準：
• 他們對成功和客戶對軟體部署的接受至關重要。
• 他們可以從多方面考驗設計，這對架構的評估至關重要。
當你确定好架構的架構級用例之後，你可以用他們來評估待測架構的成功與否。如果待測架構需要更多的用例，或者更加有效的評估架構，那麼這個待測架構是上個基本架構的改進版本了。
分析和評估架構
用架構評價來确定你的基本架構和待測架構的靈活性。架構評價是成功的架構疊代中的關鍵部分。在架構評價中考慮以下幾個技術：
• 架構級用例:用用例來測試設計對你軟體的成功非常重要。這也是你設計中的重要一環。
• 基于場景的評估：用場景來分析你的設計。并且要考慮到品質屬性。基于場景的評估有：
ü 架構權衡分析方法。
ü 軟體架構分析方法。
ü 和中間設計審查。
展示和溝通架構
把你的架構拿出來溝通在架構審查中非常重要，在架構的實施過程中尤其如此。最後，隻要你的溝通品質好，那架構的品質就有了保障。你必須和不同的角色讨論你的架構，包括系統設計者、開發人員、系統管理者等。一個可以清晰展現架構圖景的方法是決策圖。決策圖不是某個專業的東西而是一個可以幫助你和其他人溝通的抽象。
架構圖景
了解目前讓我們做出架構決策，和将來讓我們做出改變的關鍵因素。這些關鍵因素受客戶要求的影響，同時也受到業務要求的影響，比如更快的得到結果，更好的支援工作風格和工作流程的改變，以及更容易修改的設計。考慮一下關鍵趨勢：
• 使用者授權：一個支援使用者授權的設計是比較靈活的，這樣的設計是可配置的，并考慮到了使用者使用體驗。設計時考慮到使用者的個性和可能的選擇。允許使用者選擇軟體如何對操作做出回應，而不是教育訓練他們。了解關鍵的使用場景，并使軟體盡量的簡單易用，容易找到資訊和使用。
• 市場成熟：在現有平台和技術選擇的基礎上烤爐事成成熟度。在高層建立應用架構才有意義，這樣唯一的确定什麼在你的軟體中是有價值的，而不是建立一些已經存在并可以複用的。評價模式可以提供很多的已經證明了的普遍問題的解決方案。
• 靈活性和适應性：一個靈活的，适應性強的設計重點在與松耦合以支援複用。考慮插件式開發以支援擴充。考慮服務優先的技術比如soa以支援互操作。
• 未來趨勢：當你建構你的軟體的時候，了解未來可能在部署後對你的設計産生影響的趨勢。比如，考慮富用戶端和媒體，符合子產品比如混搭應用，增加的網絡貸款和可用性，移動終端的增加，硬體性能的持續改進，社群和個人出版的增加，雲計算的和遠端操作的增加等。
歡迎加群互相學習，共同進步。qq群：ios: 58099570 | android: 330987132 | go：217696290 | python：336880185 | 做人要厚道，轉載請注明出處！http://www.cnblogs.com/sunshine-anycall/archive/2009/01/17/1377377.html