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