成功的架構設計
好的架構應當具有如下品質：
- 良好的模塊化。每個模塊職責明晰，模塊之間鬆耦合，模塊內部高聚合併合理地實現了信息隱藏。
- 適應功能需求的變化，適應技術的變化。應該保持應用相關模塊和領域通用模塊的分離，技術平臺相關模塊和獨立於具體技術的模塊相分離，從而達到“隔離變化”的效果。
- 對系統的動態運行有良好的規劃。
- 對數據的良好規劃。
- 明確、靈活的部署規則。
軟件架構師的工作成功要爲整個軟件開發團隊的工作提供足夠的指導和限制，使他們能夠沿着正確的方向進行下去。軟件架構師開展架構設計工作，都是以《軟件需求規格說明書》爲最主要的設計依據的，都是先勾畫出概念性架構，再結合具體技術平臺制定實際架構。
非功能需求來自何處？一部分非功能需求來自用戶。用戶要功能，用戶也要質量。爲用戶而設計，不僅要滿足用戶要求的功能，也要達到用戶期望的質量。一部分非功能需求來自開發者和升級維護人員。軟件的可擴展性、可重用性、可移植性、易理解性和易測試性等非功能需求，都屬於“軟件開發期質量屬性”之列。還有一部分非功能需求來自客戶組織。非功能需求對架構設計非常重要。非功能需求是最重要的“架構決策因素”之一。非功能需求大致分爲質量屬性和約束兩大類。約束性需求，它們要麼是架構設計中必須遵循的限制，要麼轉化爲質量屬性需求或者功能需求。架構設計過程中必須重視非功能需求。功能很重要，當架構師不能僅盯着功能需求，若忽視了非功能需求，則可能導致架構設計的失敗。
架構師必須具備“忘卻”的能力，避免涉及太多的具體的技術細節。軟件架構必須爲開發人員提供足夠的指導和限制。軟件架構師需要掌握趨於系統化的方法。對待複雜性的辦法就是分而治之，和分而治之相伴相生的“綜合考慮”也是不可或缺的。
軟件架構設計強調的是整體，而整體性的設計決策必須基於對需求的全面認識。全面認識需求，是生產出高質量軟件所必須的“第一項修煉”。要全面認識需求，我們必須從不同級別來考察需求：組織級、用戶級、開發級，還要對每個級別考慮不同類型的需求：功能需求、質量屬性、約束。全面認識需求還有一層含義，那就是應當在深思熟慮之後作出適合的需求權衡和取捨。一方面，衆多質量屬性需求之間往往會有衝突，我們必須權衡。另一方面，如果通過複雜設計所支持的變化根本不會發生，那麼這種過度設計就造成了資源的浪費並增加了開發的難度。
讓關鍵需求決定架構。功能需求數量衆多，應該控制架構設計時需要詳細分析的用例個數；另一方面，不同質量屬性之間往往具有相互制約性，於是我們自然應該權衡哪一部分質量屬性是架構設計的重大目標。需求來自與實踐需要，而實踐是發展的，所以“確定的需求”只是相對的。我們一般在項目的業務目標以核心需求達成共識之後就開始架構設計，關鍵需求決定架構的策略非常適合。
應對軟件架構設計方案進行驗證，而不僅僅是評審。應真正地通過編碼將架構實現；應實際對架構原型進行測試，測試的重點是運行時質量屬性；要認真評估架構原型的實現過程，以對軟件架構的開發期質量屬性給出評價。有兩種驗證技術可以採用：原型技術和框架技術。
架構設計不能遺漏至關重要的非功能需求；架構設計必須馴服數量巨大且頻繁變化的需求。架構設計涉及不同方面的設計決策，軟件架構師應當採用基於多視圖的架構設計方法。架構設計的成果應及早驗證，如果盲目假設架構方案是可行的，直到後期才發現問題，就會造成大規模返工乃至項目失敗，因此軟件架構師應注意儘早驗證架構。
我們不認爲Coding和Designing是對立的。
把設計搞得玄而又玄的結果是，很多影響全局的設計決策本應由架構設計來完成的，卻統統“漏”到了後邊，最終到了大規模並行開發階段才發現。這樣一來，造成了“程序員碰頭臨時決定”的情況大量出現，軟件質量必然下降，甚至還會導致項目失敗。軟件架構是團隊開發的基礎，軟件架構必須設計到“能爲開發人員提供足夠的指導和限制”的程度。《人月神話》指出“軟件的複雜度是根本屬性，不是次要因素”。採用面向對象方法的“最重要的原因”是它可以幫助我們解決更復雜的問題，而不是更好的可重用性。面對一個複雜的問題，我們如何分而治之？可以按照問題的深度進行分而治之或者按照問題的廣度進行分而治之。接口和現實分離，就是“按問題的深度分而治之”一個很好的例子。將展現層、業務層和數據層分派給不同小組承擔，屬於“按問題廣度分而治之”的例子。
隨着軟件的規模和複雜度增加，算法和數據結構以外的設計問題就會出現：設計和制定系統整體結構將成爲新的一類問題，這就是軟件架構層次的設計。將設計分爲架構設計和詳細設計，是對“按問題深度分而治之”思想的運用：所謂架構設計，就是關於如何構建軟件的一些最重要的設計決策，這些決策往往是圍繞將系統分爲哪些部分，各個部分之間如何交互展開的。而詳細設計針對每個部分的內部進行設計。軟件架構設計應當解決的是全局性的、涉及不同“局部”之間交互的設計問題，而不同“局部”的設計由後續的詳細設計負責。在軟件架構所提供的“合作契約”的指導下，衆多局部問題被很好地“按問題廣度分而治之”了。這種先確定軟件架構，而後基於軟件架構進行並行開發的做法，綜合利用了上訴兩種分而治之的方法，利用控制複雜性，提高開發效率。
面對“技術複雜性”和“管理複雜性”這樣的雙重困難，以架構爲中心的開發方法是有效的途徑：一方面，軟件架構從大局着手，就技術方面的重大問題作出決策，構造一個具有一定抽象層次的解決方案，而不是將所有細節統統展開，從而有效地控制了“技術複雜性”。另一方面，因爲“架構中包含了關於各元素應如何彼此相關的信息”，從而可以把不同的模塊分配給不同小組分頭開發，而軟件架構設計方案在這些小組中扮演“橋樑”和“合作契約”的作用。正因爲軟件架構是大規模開發的基礎，所以架構中應包含軟件系統的各元素如何彼此相關的設計決策；也正是因爲軟件架構包含了軟件系統如何組織等關鍵決策，才能使得它能夠成爲大規模開發的基礎。由此可見，軟件架構爲開展系統化的團隊開發奠定了基礎，爲解決“管理複雜性”提供了有力的支持。
架構設計對軟件的不同部分的設計程度並不是整齊劃一的。由於項目的不同、開發團隊情況的不同，軟件架構的設計程度會有不同；軟件架構應當爲開發人員提供足夠的指導和限制。
所謂“高來高去式架構設計”，是指不能爲開發人員提夠足夠的指導和限制的那種架構設計方案。高來高去式的架構設計大致有如下三種表現：1、缺失重要架構視圖。爲不同的系統進行架構設計時，對不同的架構視圖的重視程度並不相同。“缺失重要架構視圖”的一種表現是，認爲軟件架構設計完全是用例驅動的，片面強調用例描述的功能需求。此時，架構設計對非功能需求關注不夠，既沒有深入設計軟件的運行架構，也沒有深入設計軟件的開發架構。2、淺嘗即止、不夠深入。架構方案過於籠統，基本還停留再概念性架構的層面，沒有提夠明確的技術藍圖。概念性架構對開發人員的指導和限制是不夠的。架構設計階段遺漏了全局性的設計決策，到了大規模開發實現階段，這些設計決策往往被具體開發人員從局部視角考慮並確定下來。3、名不副實的分層架構。通過分層將軟件系統模塊化之後，就迫不及待地喊出“分層架構”的口號，對各層之間交互接口和交互機制的設計嚴重不足。僅僅用分層來進行職責劃分，而沒有規劃層次之間的交互接口和交互機制的情況。缺失交互接口和交互機制的分層架構中，其實“層”已經退化成籠統意義的“職責模塊”了。
高來高去式的架構本身沒有錯，它們往往屬於概念性架構的範疇，它往往是循序漸進地進行軟件架構設計的良好起點。但是，如果停留在高來高去的架構設計上止步不前，並以之作爲最終的架構設計方案，就會爲後期開發埋下重大風險。
軟件架構設計過程
一般來說，軟件開發過程包括5個階段：概念化階段、分析階段、架構階段、架構設計階段、並行開發和測試階段、驗收與交付階段。
概念階段要解決項目的起源問題，主要針對項目目標、主要特性、功能範圍和成功要素等進行構思並達成一致。分析階段的目的是明確需求，並以《軟件需求規格說明書》的形式記錄下來。架構設計階段要在較高的抽象層次上制定解決方案，即設計軟件架構。並行開發和測試階段動用的資源是最多的，在此階段中，我們以軟件架構爲基礎，進行系統化的開發和測試。
架構設計的開展非常依賴其上游活動，這些上游活動包括需求分析和領域建模。領域建模的目的是透過問題領域的重重現象，捕捉其背後最爲穩固的領域概念及這些概念之間的關係。在項目前期，所建立的領域模型將爲所有團隊成員之間、團隊成員和客戶之間的交流提夠共同認可的語言核心。隨着項目的進展，領域模型不斷被精化，最終成爲整個軟件的問題領域層，該層決定了軟件系統能力的範圍。從項目前期伊始，軟件架構師就應該是領域建模活動的領導者。
完成了上游活動，接下來要進行概念性架構設計。軟件系統的規模越大、複雜度越高，進行概念性架構設計的好處就越明顯。概念性架構的第一步是分析關鍵用例的用例規約，接下來明確架構模式，確定交付機制，形成初步的概念性架構。概念性架構所關注的關鍵設計要素、交互機制、高層設計決策多與具體技術無關，而最終的軟件架構設計方案必須和具體技術結合，爲開發人員提供足夠的指導和限制。
儘量使架構設計策略作爲軟件架構設計過程的“一等公民”，這樣才能更有效地指導軟件架構師進行架構設計。
另外提一下領域模型建設。後面還會詳細提到。領域模型凝聚了領域專家知識。問題領域可能很複雜，領域模型揭示了紛繁複雜的問題背後的結構。領域模型和軟件需求不同：領域模型是對問題領域“做透視”，從而揭示其內在結構；而軟件需求是對問題領域“拍照片”，從而捕捉其外在功能。領域模型相對是穩定的，而軟件需求是變化的，一個優秀的領域模型可以“容納”一定程度的需求變化。領域模型是團隊交流的基礎，是所有團隊成員所用語言的核心。
軟件需求式委託方希望軟件系統達到的目標。軟件需求不僅包括功能需求，還包括質量屬性和約束性屬性。軟件架構強調的是整體，而整體性的設計決策必須基於對需求的全面認識。另外，軟件架構應該是穩定的。概念性架構是架構設計的初步成果。概念性架構也會確定軟件系統所採用的架構模式。對軟件架構起關鍵作用的質量屬性需求將在“質量屬性分析”活動中進行。架構設計不斷深入的過程，也是領域模型不斷精化的過程。隨着用例分析的進行，不斷有類的職責被確定，作爲類的方法被添加進來。最終的軟件架構設計方案必須和具體技術結合，從而爲開發人員提夠足夠的指導和限制。在設計軟件的邏輯架構過程中，領域模型將進一步精化，併成爲軟件邏輯架構的重要組成部分。
