《軟件架構設計》學習筆記（轉）

架構的概念

在軟件行業，架構的概念一直沒有一個完整、統一的定義，軟件架構的概念分爲主要量大派別：組成派和決策派。組成派認爲軟件架構是：軟件系統的架構將系統描述爲計算組件及組件之間的交互，「組件」是普遍意義上的元素，並非指具體的技術組件。組成派的定義關注架構實踐中的客體——軟件，以及軟件自己爲描述對象；另外分析了軟件的組成，即軟件由承擔不一樣計算任務的組成組件，這些組件經過相互交互完成更高層次的計算。而決策派認爲，軟件架構保護了軟件設計過程當中一些列問題的重要決策，軟件架構並不只僅關注軟件自己的結構和行爲，還注重其餘特性：使用、功能、性能、彈性、重用、可理解性、經濟、和計算限制、權衡、以及美學等。決策派的定義更關注架構實踐中的主體——人，以人的決策爲描述對象，而且概括了架構決策的類型，指出架構決策不只包括關於軟件系統的組織、元素、子系統和架構風格等幾類決策，還包括關於衆多非功能需求的決策。

說的更通俗一點，組成派關注架構的結果，而決策派關注架構的過程。而筆者認爲，架構的是一個演進的過程，沒有一成不變的架構，也沒有一蹴而就的架構，架構須要根據業務的發展而進行相應的調整，因此咱們應該更加關注架構演進的過程和緣由，以及在當時背景下的作出的權衡和妥協。沒有完美的架構，架構也沒有一個標準的解決方案，由於面對不一樣的業務需求，面對不一樣的客觀因素，有不一樣的架構設計方案，也就是有不一樣的設計決策。組成派和決策派的架構概念並不矛盾，它們只不過是所站的角度不一樣罷了：在具體的軟件架構實際中，老是同時體現這兩「派」的架構概念。 架構決策是分層次依次展開的，決策制定的順序每每是先制定技術無關的決策，後製定技術相關的決策，後者在前者的指導下進行。架構師必定要考慮更多的實際開發中要涉及到的技術問題，從而不斷細化架構方案，這樣才能爲開發人員提供更多的指導和限制，也才能真正下降後續開發中的重大技術風險。因此，架構師的架構方案不是高來高去的，而是須要可以落地的，而且在落地的過程當中遇到的技術細節問題，架構師是須要參與解決的。這樣架構師才能與開發人員無縫對接，架構方案才能指導開發人員進行開發。

子系統、框架和架構

好的架構必須使每一個關注點相互分離。把變化點錯落有致地封裝到軟件系統的不一樣部分（筆者感悟：封裝的思想在軟件工程中，無處不在啊！），爲此，必須進行關注點分離。經過關注點的分離來達到「系統中的一部分發生了變化，不會影響其餘部分」的目標。能夠經過以下的一下手段：

一、 經過職責劃分來分離關注點。面向對象設計的關鍵所在，就是職責的識別和分配。不管是對象、模塊，仍是子系統，它們所承擔的職責都應該具備高內聚性，不然對象之間的鬆耦合性就失去了基礎，成爲空談。因此咱們一直在提「高內聚、低耦合」，高內聚纔是低耦合的基礎。而咱們常用的設計模式和架構模式爲特定上下文中重複出現的問題提供了通用的職責劃分方案，也是問題解決方案。

二、 利用軟件系統各部分的通用性的不一樣進行關注點分離。不一樣的通用程度意味着變化的可能性不一樣。這一點與面向對象設計裏面的重用發佈等價原則殊途同歸。

三、 先考慮大粒度的子系統，而暫時忽略子系統是如何經過更小粒度的模塊和類組成的。避免陷入過多的細節當中，所謂「忘倒是一種能力」，就是指架構師必須有在更高層面思考的能力。 根據職責分離關注點、根據通用性分離關注點、根據不一樣粒度級別分離關注點是3種位於不一樣「維度」的思惟方式，咱們能夠綜合運用這些手段。

不管是架構模式仍是設計模式，重點關注的都是如何提供一個「協做模型」，這個協做模型經過明確協做中不一樣的角色鎖擔任的職責，達到「爲特定上下文的問題提供解決方案」的目的。

框架技術有助於把通用關注點和專用關注點分離開來，結果是帶來了更好的易修改性和可重用性。

做爲架構師，必須思考「軟件單元是如何組成粒度更大的總體的」這一問題。類、模塊、子系統、系統、集成系統，都是軟件單元的具體形態，只不過粒度不一樣罷了。軟件系統越複雜，不一樣粒度的分解層次就越多。這裏所謂的系統，是指由多個元素組成的邏輯實體，它完成一組特定的目標或負擔必定的職責。系統能夠僅包含軟件，也能夠僅包含硬件，或者二者都包含。子系統是特殊的系統，只不過在特定的上下文中，這個系統做爲更大系統的一部分出現。系統須要架構設計，而子系統若是足夠複雜，則也須要架構設計。而不一樣類型的軟件系統須要不一樣的軟件架構設計，一個系統的不一樣子系統也應當有不一樣的軟件架構。

固然，一個系統的粒度是具備相對性的，同一個軟件單元，在不一樣場景下，咱們會以不一樣的粒度看待它。全部的系統都有子系統，而全部系統都是更大系統的子系統。實踐不一樣場景使得軟件組成單元具備遞歸性。懂得了細節是相對而言的這一點，軟件架構師纔可以遊刃有餘地根據狀況忽略應該被忽略的細節，抓住設計大局。

框架的概念，框架是一種半成品。是能夠經過某種回調機制進行擴展的軟件系統或子系統的半成品。框架從某種程度上來講，是爲了軟件重用。而軟件重用自己又有一對內在的矛盾，即重用概率和重用價值，重用概率大小和重用帶來的價值大小之間的矛盾。軟件單元的粒度越大，可重用的概率就越小，但其重用所帶來的價值就越大，相反，軟件單元的粒度越小，可重用概率就越大，但其重用所帶來的價值就越小。框架的智慧就在於此：爲了追求重用所帶來的價值最大化，將容易變化的的部分封裝成擴展點，並輔以回調機制將它們歸入框架的控制範圍以內。 對軟件架構的誤解，其中一個最爲廣泛的就是，將架構（Acrchitecture）和框架（Framework）混爲一談。框架是軟件，而架構不是軟件。框架是一種特殊的軟件，它並不能提供完整的解決方案（準確說，是不提供業務應用的完整解決方案，而框架自己也是爲解決某一類問題而出現的），而是爲構建解決方案（這裏的解決方案便是業務應用的解決方案）提供良好的基礎，因此說，框架是半成品。框架中的服務能夠被最終應用直接調用，而框架中的擴展點是供應用開發人員定製的「可變化點」。而軟件架構不是軟件，而是關於軟件如何設計的重要決策。軟件架構決策涉及到如何將軟件系統分解成不一樣的部分、各部分之間的靜態結構關係和動態交互關係等。這些架構決策將體如今最終開發出的軟件系統中。引入軟件框架以後，整個開發過程變成了分兩步走，而架構決策每每會體如今框架之中。軟件架構是比具體代碼高一個抽象層次的概念。架構勢必被代碼所體現和遵循，但任何一段具體的代碼都表明不了架構（這裏說的有點絕對，某一段具體的代碼，表明不了整個架構，有時卻能夠表明某一個架構決策）。框架技術和架構技術的出現，都是爲了解決軟件系統日益複雜所帶來的困難而採起「分而治之」的思想。先大局後局部，就出現了架構；先通用後專用，就出現了框架。架構是問題的抽象解決方案，它關注大局而忽略細節；框架是通用半成品，還必須根據具體需求進一步定製開發才能變成應用系統。固然，框架也有架構，並且很重要。框架和架構既有區別又有聯繫，前者是複合組件特例，後者是複合組件的大局設計。軟件架構須要落地，須要瞭解細節，但也沒有必要將全部設計決策事無鉅細地落實，而是重點關注「重要決策」。軟件架構設計的決策範圍，應該着重放在「影響全局」的設計上，而不是所關注全部設計細節。

對面向對象開發而言，類庫和框架有不少共同之處，但它們確確實實又是不一樣的。類庫是類的集合，這些類之間多是相互獨立的。與類庫相比，框架和類庫有着類似的形式，即框架也每每是類的集合，但不一樣之處在於，框架中的各個類不是孤立的，而框架中的業務邏輯代碼是將不一樣的類「連」在一塊兒，在它們之間創建協做關係。框架經過封裝處理流程的控制邏輯，使它對開發者透明，來簡化開發工做。這種封裝也是框架和類庫的區別之一。

框架能夠分爲應用框架、中間件框架和基礎設施框架三大類，造成了「應用軟件——中間件——基礎設施」的宏觀格局。框架也能夠分爲技術框架和業務框架。技術框架又稱爲水平框架，業務框架有稱爲垂直框架。框架的整個開發過程，包括四個主要階段，即分析、設計、實現和穩定階段。和應用開發同樣，框架開發首先要肯定框架的範圍和目標。對特定領域框架層和跨領域框架層都要識別出通用點和擴展點，其次，爲框架設計架構，將它用做實現階段的藍圖。在設計階段，也能夠建立應用程序框架原型，而後在其上構建一個樣本應用，並洞察框架設計中潛在的可改進之處。框架開發的穩定階段還應提供相應的框架文檔。面向對象技術的發展極大提夠了框架的能力，並推進了框架技術被廣泛接受。面向對象框架的組成部分包括具體類、抽象類和接口。抽象方法是面向對象支持「多態」的關鍵，面向對象框架藉助抽象方法實現逆向控制。許多面向對象框架在利用抽象方法支持擴展的同時，還會藉助「配置驅動」來下降使用框架的難度。框架也須要架構設計，但反過來，能夠經過架構框架化，達到「架構重用」的目的。

軟件架構的做用

軟件架構對後期的軟件維護，乃至改動力度比較大的軟件升級都起着重要做用。由於軟件架構給出了軟件系統的一個全局的視角。對軟件系統不斷的修改會使系統架構慢慢變得混亂，由於業務的發展，是會慢慢腐蝕現有的系統架構的，因此架構須要根據業務的發展進行演進。 軟件架構設計爲何這麼難？由於它是跨越現實世界與計算機世界之間鴻溝的一座橋。從面向業務的需求，到最終的面向技術的軟件系統，要跨越很大的鴻溝。軟件架構設計就是要完成從面向業務到面向技術的轉換，在鴻溝上駕起一座橋樑。軟件架構包含告終構、協做和技術等方面的重要決策，爲系統化的開發活動創建了基礎。

架構的做用包括以下幾個方面：

一、 上承業務目標：擔負着完成業務目標而進行大局規劃的職責。

二、 下接技術決策：軟件架構師將面向業務的需求轉化爲面向技術的軟件架構設計方案，爲後面的技術開發工做提供了切實的指導和限制。

三、 控制複雜性：先進行架構設計，後進行詳細設計和編碼實現，運用了「基於問題深度分而治之」的理念，利用控制複雜性。

四、 組織開發：軟件架構爲開展系統化的團隊開發奠基了基礎，它規定了軟件系統的各元素如何彼此相關的設計決策，從而能夠把不一樣模塊分配給不一樣小組分頭併發進行，而軟件架構設計方案在這些小組中間扮演了「橋樑」和「合做契約」的做用。

五、 利用迭代開發和增量交互

六、 提升質量：清晰的軟件架構將各個模塊的職責劃分得有條不絮，每一個模塊都有清晰的接口，這至關於間接下降了開發難度。

軟件架構會「磨損」——隨着對軟件系統不斷地修改，軟件架構將變得混亂。

所謂軟件架構重構，是指對軟件架構進行比較大的修改和調整，使它適應新需求及開發和維護的須要。軟件架構重構屬於「再工程」的一種狀況，通常會經歷逆向工程、從新規劃、正向工程三個步驟。只有充分理解原有架構的設計思路，才能評估它在如今需求狀況的「利」和「弊」，把合理的設計保留下來，把不妥的設計修改掉。

軟件架構視圖

方法指導過程，過程包含步驟。

所謂軟件架構就是關於如何構建軟件的一些最重要的設計的決策，這些決策每每是圍繞將系統分爲哪些部分、各部分之間如何交互展開的。不一樣的涉衆看待軟件架構的視角是不一樣的。軟件架構是抽象的概念，因此在軟件架構概念與實踐之間，彷佛存在某種「鴻溝」——即缺失某種概念，而這種概念能夠「連接」軟件架構的概念和實際的開發實際的須要，爲不一樣涉衆理解和交流架構提供更專注的視角。爲了在軟件架構純概念和實踐之間搭起一座橋樑，能夠引入軟件架構視圖的概念。軟件架構師應當時時牢記：爲用戶而設計，不只知足用戶要求的功能，也要達到用戶指望的質量。架構師也必須爲客戶而設計，適合的纔是最好的。架構師還應該爲開發人員而設計，關注軟件的「開發期質量屬性」（可擴展性、可移植性、易理解性和易測試性等非功能需求，都是屬於軟件開發期質量屬性），爲開發人員而設計。軟件愈來愈複雜，單兵做戰已經再也不是廣泛的軟件開發方式，取而代之的是團隊開發，而團隊開發又反過來使軟件開發更加複雜，由於如今不只僅要面臨技術複雜性的問題了，還有管理複雜性的問題。軟件架構從大局着手，就技術方面的重大問題作出決策，構造一個由粗粒度模塊組成的解決方案，從而能夠把不一樣模塊分配給不一樣小組分頭開發。另外一方面，軟件架構設計方案規定了各模塊之間如何交互的機制和接口，在開發小組之間起到「溝通橋樑」和「合做契約」的做用。配置管理員應該可以從軟件架構方案中瞭解到開發出來的軟件以什麼樣的目錄結構存在，以及編譯事後的軟件目標模塊放到哪一個目錄等決定，並以此做爲制定配置管理基本方案的基礎。因此，架構師應該爲項目相關不一樣的角色而設計。軟件架構師必須作到內外兼修、各層並重。只有這樣，軟件架構才能和它「包含了關於如何構建軟件的一些最重要的設計決策」的「地位」相符。

一個軟件架構視圖是對與從某一視角或某一點上看到的系統所做出的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了與此方面無關的實體。軟件架構的每一個視圖分別關注不一樣的方面，針對不一樣的目標和用戶。軟件架構師應當提供不一樣的軟件架構視圖，以便交流和傳遞設計思想。每一個軟件架構視圖關注軟件架構不一樣的方面，使問題得以清晰和簡化，利於軟件架構師完成架構設計的工做。項目不一樣角色觀察軟件架構的視角各不相同，每一個視角涉及的需求和技術也不盡相同，因此將軟件架構視圖用做軟件歸檔的手段是順利成章的：但更爲重要的是，軟件架構視圖能夠被相對獨立地分析和設計，這就使得軟件架構師能夠暫時撇開其餘問題、專一於特定問題進行深刻的分析和設計。

最經常使用的兩種架構視圖：邏輯架構視圖和物理架構視圖。當觀察和描述事物大局的時候，邏輯架構和物理架構是最經常使用的角度。軟件邏輯架構設計的三大核心任務：識別功能塊；規劃功能塊的接口；明確功能塊之間的使用關係和使用機制。軟件的邏輯架構是架構設計思惟的重要方法。用例技術已經成爲捕獲功能需求的事實標準，因此邏輯架構的設計每每是從用例分析開始的。基於用例的分析方法使邏輯架構的設計變得比較有序——經過對每一個關鍵用例的分析，從邏輯上將用例實現爲一組功能塊的特定組合，最後綜合這些用例分析成果，獲得整個軟件系統的邏輯架構。物理架構能夠反映出軟件系統運行時的組織狀況。「物理元素」就進程、線程以及做爲類的運行時實例的對象等，而進程調度、線程同步、進程或線程通訊等則進一步反映物理架構的動態行爲。物理層和分別有關，經過將一個總體的軟件系統劃分爲不一樣的物理層次，能夠把它部署到分別在不一樣位置的多臺計算機上，從而爲遠程訪問和負載均衡等問題提供了手段。物理層是大粒度的物理單元，它最終是由粒度更小的組件、模塊和進程等單元組成。邏輯架構和物理架構是軟件架構設計的重要方面。邏輯架構致力於將軟件系統分解成不一樣的邏輯單元，並規定這些邏輯單元之間的交互接口和交互機制。物理架構則更重視軟件系統運行時的動態結構，以及組成軟件系統的目標程序如何部署到硬件上。邏輯架構中關於職責劃分的決策，體現爲層、子系統和模塊等的劃分決定，從靜態視角爲詳細設計和編程實現提供切實的指導；有了分解就必然產生協做，邏輯架構還規定了不一樣邏輯單元之間的交互接口和交互機制，而編程工做必須實現這些接口和機制。所謂交互機制，就是指不一樣軟件單元之間的交互手段。交互機制能夠是本地方法調用、基於RMI的遠程方法調用、異步消息等。至於物理架構，它關注的是軟件系統在計算機中運行期間的狀況。軟件的物理架構關注「目標程序及其依賴的運行庫和系統軟件」最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等需求。物理層做爲組成軟件系統的物理單元，最終又要映射到具體的硬件，這也是物理架構設計要考慮的，對於分佈式軟件系統的設計而言尤爲不可或缺。

不一樣的視圖支持不一樣的目標和用途。

軟件架構師有許多工做要作：

一、要知足性能、持續可用性等方面的需求，架構師必須深刻研究軟件系統運行期間的狀況、制定相應的設計決策，這些需求被稱爲軟件的「運行期質量屬性」；

二、而要知足可擴展性、可重用性等方面的需求，則要求架構師深刻研究軟件系統開發期間的狀況，制定相應的設計決策，這些需求被稱爲軟件「開發期質量屬性」；

三、約束是一類特殊的需求，帶有必定強制性，架構師制定的架構決策必須知足這些限制；

四、爲了知足功能需求，架構師必須規劃組成軟件系統的全部模塊，爲他們分配不一樣職責，使這些模塊能夠經過協做完成功能需求。

架構師必須明確區分功能需求、約束、運行期質量屬性和開發期質量屬性等不一樣種類的需求。

架構設計的5視圖方法包括：邏輯架構、開發架構、運行架構、物理架構、數據架構。邏輯架構關注功能，它們多是邏輯層、功能模塊和類等。開發架構關注程序包，不只包括要編寫的源程序，還包括能夠直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件。運行架構關注進程、線程、對象等運行時概念，以及相關的併發、同步、通訊等問題。物理架構關注「目標程序及其依賴的運行庫和系統軟件」最終如何安裝和部署到物理機器上，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。數據架構關注持久化數據的存儲方案，不只包括實體及實體關係的數據存儲格式，還可能包括數據傳遞、數據複製和數據同步等策略。

邏輯架構的設計着重考慮功能需求，系統應當向用戶提供什麼樣的服務。邏輯架構的關注點主要是行爲或職責的劃分。邏輯架構的靜態方面關注抽象職責的劃分，其動態方面關注承擔不一樣職責的邏輯單元之間的交互。開發機構的設計着重考慮開發週期質量屬性，例如可用性、可擴展性、易理解性和易測試性等。開發架構的關注點是在軟件開發環境中軟件模塊的實際組織方式。運行架構的設計着重考慮運行期質量屬性，例如性能、可伸縮性、持續可用性和安全性等。運行架構的關注點是系統的併發與同步等問題，這勢必涉及到進程和線程等技術。運行架構的靜態方面關注軟件的運行時單元結構，其動態方面則關注運行時單元之間的交互機制。物理架構的設計着重考慮「安裝和部署需求」，另外物理架構還應關注相關的可靠性、可伸縮性、持續可用性、性能和安全性等方面。數據架構的設計着重考慮「數據需求」。數據架構的關注點是持久化數據的組織、數據傳輸、數據複製和數據同步等策略。

五種架構視圖，反映的是同一個軟件系統的不一樣設計方面，它們最終合在一塊兒纔是完整的架構設計方案，因此不一樣的架構視圖之間勢必有相互支撐的關係。所謂保持架構視圖之間的同步，就是保證不一樣視圖之間是相互解釋而不是相互矛盾的。若是須要，能夠引入新的架構視圖，從而更加突出和明確地制定和表達特定方面的架構決策。另外，約束是必須遵照和考慮到的，每一個架構設計視圖都應該注意這一點。五種不一樣的元素撐起了不一樣的思惟空間，從而使每一個架構視圖重點覆蓋不一樣種類的需求。

概念架構和實際架構

實際的軟件架構設計過程是，通常應先進行概念性架構的設計，把最關鍵的設計要素和交互機制肯定下來，而後再考慮具體技術的運用，設計出實際架構。概念性架構是對系統設計的最初構想。概念性架構沒有嚴格的定義，並且也不該該過於嚴格的定義。概念性架構包括一些高層次的設計選擇，對將來軟件系統的質量和功能都起着關鍵影響。複雜系統的設計每每不能一蹴而就，而概念性架構就是最初的架構設計成果。

經典的分層架構的層指邏輯層（Layer），而如今的分佈式應用的分層架構是指物理層（Tier）。邏輯層是一種功能和職責的組織單元，而物理層要求功能和責任的高聚合性，只不過每每是經過多個邏輯層映射到一個物理層這種方式實現的。

雖然概念性架構都跳不出「架構=組件+交互」的基本定義，但它們描述架構的具體方式仍是差別很大的：有的重視邏輯層，有的重視物理層，有的經過隱喻代表機制，有的看上去彷佛就是一些設計元素的組合。不一樣的概念性架構圖中，「鏈接」所表明的含義千差萬別：有的是依賴方向，有的是控制方向，有的是數據流向。因爲概念架構的高度抽象性，使得同屬一類的許多軟件產品的概念性架構是趨同的。概念性架構很是類似，實際架構卻可能有很大的差別。概念性架構每每和具體技術的運用、具體平臺的選擇無關，而實際架構很是關心這些問題。實際的架構設計方案應該兼顧不一樣的架構設計視圖。概念性架構所包含的高層設計決策終究不會跳出以下多種架構視圖的範圍——邏輯架構、物理架構、開發架構、數據架構和運行架構。而實際架構必須設計到能夠指導開發的程度。但務實地來說，概念性架構常常從邏輯架構和物理架構的角度制定高層設計決策。

概念性架構是不可直接實現的。概念性架構和實際架構的一些區別，主要涉及到開發人員最關心的點：

一、接口如何定義；

二、子系統如何劃分；

三、各子系統或模塊之間的如何進行交互；

共同點：概念性架構和實際架構都知足軟件架構的概念——不管是「架構=組件+交互」，仍是「架構=重要的決策集」。

分層架構每每是咱們架構思惟的開始，在「分層」的基礎上如何深刻，細化設計，如何調整每每是架構設計的關鍵。

概念性架構每每和具體技術的運用和具體平臺的選擇無關，而實際架構則很是關係這些問題，概念性架構並不規定要採用OO技術，但設計實際架構時每每要考慮如何充分利用OO技術來實現概念性架構。從概念性架構到實際架構，先設計概念性架構，構思關鍵問題的解決策略；再進行實際架構設計，以保證爲開發提供足夠的指導和限制。

成功的架構設計

好的架構應當具備以下品質：

一、良好的模塊化。每一個模塊職責明晰，模塊之間鬆耦合，模塊內部高聚合併合理地實現了信息隱藏。

二、適應功能需求的變化，適應技術的變化。應該保持應用相關模塊和領域通用模塊的分離，技術平臺相關模塊和獨立於具體技術的模塊相分離，從而達到「隔離變化」的效果。

三、對系統的動態運行有良好的規劃。

四、對數據的良好規劃。

五、明確、靈活的部署規則。

軟件架構師的工做成功要爲整個軟件開發團隊的工做提供足夠的指導和限制，使他們可以沿着正確的方向進行下去。軟件架構師開展架構設計工做，都是以《軟件需求規格說明書》爲最主要的設計依據的，都是先勾畫出概念性架構，再結合具體技術平臺制定實際架構。

非功能需求來自何處？一部分非功能需求來自用戶。用戶要功能，用戶也要質量。爲用戶而設計，不只要知足用戶要求的功能，也要達到用戶指望的質量。一部分非功能需求來自開發者和升級維護人員。軟件的可擴展性、可重用性、可移植性、易理解性和易測試性等非功能需求，都屬於「軟件開發期質量屬性」之列。還有一部分非功能需求來自客戶組織。非功能需求對架構設計很是重要。非功能需求是最重要的「架構決策因素」之一。非功能需求大體分爲質量屬性和約束兩大類。約束性需求，它們要麼是架構設計中必須遵循的限制，要麼轉化爲質量屬性需求或者功能需求。架構設計過程當中必須重視非功能需求。功能很重要，當架構師不能僅盯着功能需求，若忽視了非功能需求，則可能致使架構設計的失敗。

架構師必須具有「忘卻」的能力，避免涉及太多的具體的技術細節。軟件架構必須爲開發人員提供足夠的指導和限制。軟件架構師須要掌握趨於系統化的方法。對待複雜性的辦法就是分而治之，和分而治之相伴相生的「綜合考慮」也是不可或缺的。

軟件架構設計強調的是總體，而總體性的設計決策必須基於對需求的全面認識。全面認識需求，是生產出高質量軟件所必須的「第一項修煉」。要全面認識需求，咱們必須從不一樣級別來考察需求：組織級、用戶級、開發級，還要對每一個級別考慮不一樣類型的需求：功能需求、質量屬性、約束。全面認識需求還有一層含義，那就是應當在深思熟慮以後做出適合的需求權衡和取捨。一方面，衆多質量屬性需求之間每每會有衝突，咱們必須權衡。另外一方面，若是經過複雜設計所支持的變化根本不會發生，那麼這種過分設計就形成了資源的浪費並增長了開發的難度。 讓關鍵需求決定架構。功能需求數量衆多，應該控制架構設計時須要詳細分析的用例個數；另外一方面，不一樣質量屬性之間每每具備相互制約性，因而咱們天然應該權衡哪一部分質量屬性是架構設計的重大目標。需求來自與實踐須要，而實踐是發展的，因此「肯定的需求」只是相對的。咱們通常在項目的業務目標以核心需求達成共識以後就開始架構設計，關鍵需求決定架構的策略很是適合。

應對軟件架構設計方案進行驗證，而不只僅是評審。應真正地經過編碼將架構實現；應實際對架構原型進行測試，測試的重點是運行時質量屬性；要認真評估架構原型的實現過程，以對軟件架構的開發期質量屬性給出評價。有兩種驗證技術能夠採用：原型技術和框架技術。

架構設計不能遺漏相當重要的非功能需求；架構設計必須馴服數量巨大且頻繁變化的需求。架構設計涉及不一樣方面的設計決策，軟件架構師應當採用基於多視圖的架構設計方法。架構設計的成果應及早驗證，若是盲目假設架構方案是可行的，直到後期才發現問題，就會形成大規模返工乃至項目失敗，所以軟件架構師應注意儘早驗證架構。

咱們不認爲Coding和Designing是對立的。

把設計搞得玄而又玄的結果是，不少影響全局的設計決策本應由架構設計來完成的，卻通通「漏」到了後邊，最終到了大規模並行開發階段才發現。這樣一來，形成了「程序員碰頭臨時決定」的狀況大量出現，軟件質量必然降低，甚至還會致使項目失敗。軟件架構是團隊開發的基礎，軟件架構必須設計到「能爲開發人員提供足夠的指導和限制」的程度。《人月神話》指出「軟件的複雜度是根本屬性，不是次要因素」。採用面向對象方法的「最重要的緣由」是它能夠幫助咱們解決更復雜的問題，而不是更好的可重用性。面對一個複雜的問題，咱們如何分而治之？能夠按照問題的深度進行分而治之或者按照問題的廣度進行分而治之。接口和現實分離，就是「按問題的深度分而治之」一個很好的例子。將展示層、業務層和數據層分派給不一樣小組承擔，屬於「按問題廣度分而治之」的例子。

隨着軟件的規模和複雜度增長，算法和數據結構之外的設計問題就會出現：設計和制定系統總體結構將成爲新的一類問題，這就是軟件架構層次的設計。將設計分爲架構設計和詳細設計，是對「按問題深度分而治之」思想的運用：所謂架構設計，就是關於如何構建軟件的一些最重要的設計決策，這些決策每每是圍繞將系統分爲哪些部分，各個部分之間如何交互展開的。而詳細設計針對每一個部分的內部進行設計。軟件架構設計應當解決的是全局性的、涉及不一樣「局部」之間交互的設計問題，而不一樣「局部」的設計由後續的詳細設計負責。在軟件架構所提供的「合做契約」的指導下，衆多局部問題被很好地「按問題廣度分而治之」了。這種先肯定軟件架構，然後基於軟件架構進行並行開發的作法，綜合利用了上訴兩種分而治之的方法，利用控制複雜性，提升開發效率。

面對「技術複雜性」和「管理複雜性」這樣的雙重困難，以架構爲中心的開發方法是有效的途徑：一方面，軟件架構從大局着手，就技術方面的重大問題做出決策，構造一個具備必定抽象層次的解決方案，而不是將全部細節通通展開，從而有效地控制了「技術複雜性」。另外一方面，由於「架構中包含了關於各元素應如何彼此相關的信息」，從而能夠把不一樣的模塊分配給不一樣小組分頭開發，而軟件架構設計方案在這些小組中扮演「橋樑」和「合做契約」的做用。正由於軟件架構是大規模開發的基礎，因此架構中應包含軟件系統的各元素如何彼此相關的設計決策；也正是由於軟件架構包含了軟件系統如何組織等關鍵決策，才能使得它可以成爲大規模開發的基礎。因而可知，軟件架構爲開展系統化的團隊開發奠基了基礎，爲解決「管理複雜性」提供了有力的支持。

架構設計對軟件的不一樣部分的設計程度並非整齊劃一的。因爲項目的不一樣、開發團隊狀況的不一樣，軟件架構的設計程度會有不一樣；軟件架構應當爲開發人員提供足夠的指導和限制。

所謂「高來高去式架構設計」，是指不能爲開發人員提夠足夠的指導和限制的那種架構設計方案。高來高去式的架構設計大體有以下三種表現：一、缺失重要架構視圖。爲不一樣的系統進行架構設計時，對不一樣的架構視圖的重視程度並不相同。「缺失重要架構視圖」的一種表現是，認爲軟件架構設計徹底是用例驅動的，片面強調用例描述的功能需求。此時，架構設計對非功能需求關注不夠，既沒有深刻設計軟件的運行架構，也沒有深刻設計軟件的開發架構。二、淺嘗即止、不夠深刻。架構方案過於籠統，基本還停留再概念性架構的層面，沒有提夠明確的技術藍圖。概念性架構對開發人員的指導和限制是不夠的。架構設計階段遺漏了全局性的設計決策，到了大規模開發實現階段，這些設計決策每每被具體開發人員從局部視角考慮並肯定下來。三、名存實亡的分層架構。經過分層將軟件系統模塊化以後，就火燒眉毛地喊出「分層架構」的口號，對各層之間交互接口和交互機制的設計嚴重不足。僅僅用分層來進行職責劃分，而沒有規劃層次之間的交互接口和交互機制的狀況。缺失交互接口和交互機制的分層架構中，其實「層」已經退化成籠統意義的「職責模塊」了。

高來高去式的架構自己沒有錯，它們每每屬於概念性架構的範疇，它每每是按部就班地進行軟件架構設計的良好起點。可是，若是停留在高來高去的架構設計上止步不前，並以之做爲最終的架構設計方案，就會爲後期開發埋下重大風險。

軟件架構設計過程

通常來講，軟件開發過程包括5個階段：概念化階段、分析階段、架構階段、架構設計階段、並行開發和測試階段、驗收與交付階段。 概念階段要解決項目的起源問題，主要針對項目目標、主要特性、功能範圍和成功要素等進行構思並達成一致。分析階段的目的是明確需求，並以《軟件需求規格說明書》的形式記錄下來。架構設計階段要在較高的抽象層次上制定解決方案，即設計軟件架構。並行開發和測試階段動用的資源是最多的，在此階段中，咱們以軟件架構爲基礎，進行系統化的開發和測試。

架構設計的開展很是依賴其上游活動，這些上游活動包括需求分析和領域建模。領域建模的目的是透過問題領域的重重現象，捕捉其背後最爲穩固的領域概念及這些概念之間的關係。在項目前期，所創建的領域模型將爲全部團隊成員之間、團隊成員和客戶之間的交流提夠共同承認的語言核心。隨着項目的進展，領域模型不斷被精化，最終成爲整個軟件的問題領域層，該層決定了軟件系統能力的範圍。從項目前期伊始，軟件架構師就應該是領域建模活動的領導者。

完成了上游活動，接下來要進行概念性架構設計。軟件系統的規模越大、複雜度越高，進行概念性架構設計的好處就越明顯。概念性架構的第一步是分析關鍵用例的用例規約，接下來明確架構模式，肯定交付機制，造成初步的概念性架構。概念性架構所關注的關鍵設計要素、交互機制、高層設計決策多與具體技術無關，而最終的軟件架構設計方案必須和具體技術結合，爲開發人員提供足夠的指導和限制。

儘可能使架構設計策略做爲軟件架構設計過程的「一等公民」，這樣才能更有效地指導軟件架構師進行架構設計。

另外提一下領域模型建設。後面還會詳細提到。領域模型凝聚了領域專家知識。問題領域可能很複雜，領域模型揭示了紛繁複雜的問題背後的結構。領域模型和軟件需求不一樣：領域模型是對問題領域「作透視」，從而揭示其內在結構；而軟件需求是對問題領域「拍照片」，從而捕捉其外在功能。領域模型相對是穩定的，而軟件需求是變化的，一個優秀的領域模型能夠「容納」必定程度的需求變化。領域模型是團隊交流的基礎，是全部團隊成員所用語言的核心。

軟件需求式委託方但願軟件系統達到的目標。軟件需求不只包括功能需求，還包括質量屬性和約束性屬性。軟件架構強調的是總體，而總體性的設計決策必須基於對需求的全面認識。另外，軟件架構應該是穩定的。概念性架構是架構設計的初步成果。概念性架構也會肯定軟件系統所採用的架構模式。對軟件架構起關鍵做用的質量屬性需求將在「質量屬性分析」活動中進行。架構設計不斷深刻的過程，也是領域模型不斷精化的過程。隨着用例分析的進行，不斷有類的職責被肯定，做爲類的方法被添加進來。最終的軟件架構設計方案必須和具體技術結合，從而爲開發人員提夠足夠的指導和限制。在設計軟件的邏輯架構過程當中，領域模型將進一步精化，併成爲軟件邏輯架構的重要組成部分。

原文：http://www.uml.org.cn/zjjs/201307151.asp