架構設計中各個步驟的位置
以下是對架構設計的每個步驟，進行總括的描述
1 需求分析
需求分析，是很多活動的統稱，它是“架構設計過程”中第1個大的工作步驟。
需求分析活動輸出的“需求”，必須涵蓋功能、質量、約束這三個方面，這些是后續設計活動所需要的。需求分析工作涉及的“技能項”較多，總體而言可總結為“兩縱三橫”，如圖所示：
· 【一縱】需求溝通。持續伴隨需求分析過程的，是需求溝通、需求啟發、需求驗證等活動，這些活動都要求需方和開發方緊密協同、精誠合作。“閉門造需”危險大了。
· 【二縱】非功能需求的確定。真實的實踐中，確定非功能需求是一個持續的過程，是持久戰。究其原因，這是非功能需求的范圍廣造成的，無論是技術還是業務、無論是甲方還是乙方，都可能有這樣那樣的非功能需求。想“一蹴而就”地定義非功能需求是不現實的。
· 【三橫】需求分析主線。從確定系統目標開始，后續憑借“范圍+Feature+上下文圖”三劍客研究高層需求，再后續建立開發人員較熟悉的用例模型。
做不到“追根溯源”的需求分析，往往會失敗。因此，我們補充圖4-6來強調需求分析工作的主線是“確定系統目標→研究高層需求→建立用例模型”，需求從“高飄”到“落地”，成果項從“目標列表”到“范圍框圖 + Feature樹 + 上下文圖”到“用例圖 + 用例規約”，需求跟蹤脈絡清晰可辨。
需求分析的主線體現“追根溯源”
2 領域建模
領域建模，是以提煉領域概念，建立領域模型為目的的活動。領域建模實踐的精髓是“業務決定功能，功能決定模型”，理解了這個理念，評審領域模型也變得再自然不過了。
領域建模活動的輸入：一是“功能”，二是“可擴展性”具體要求。
功能指目前所需要的，可擴展性指以后需要的說到底，都是“功能”，因為領域模型必須能支持在《軟件需求規格說明書》中規定的“現在的功能”，還應該支持隨着業務發展而出現的“未來的功能”。這兩種功能，就是驅動領域建模的因素，以及評審領域模型的依據。
3.確定關鍵需求
架構面前所有需求一律平等？不可能。關鍵需求決定了架構的大方向。
具體而言，為了確定“關鍵功能”，一要關注“功能需求”，二要研究“約束需求”；為了確定“關鍵質量”，一要關注“質量需求”，二要研究“約束需求”。
4.概念架構設計
概念架構是高層架構成果的核心，框定了架構大方向，是甲方規划、乙方投標的評定關鍵。
概念性架構界定系統的高層組件，以及它們之間的關系。概念性架構意在對系統進行適當分解，而不陷入細節。借此，可以與管理人員、市場人員、用戶等非技術人員交流架構。概念性架構規定了每個組件的非正式規約及架構圖，但不涉及接口細節。
概念架構設計要“直指”的、以之為輸入的，是“關鍵需求”。
針對不同需求（功能或者質量），需要運用不同“技能項”，魯棒圖建模、目標-場景-決策表，非常實用。
概念架構設計的“輸出”是“1個決定、4個選擇”：
1）決定如何划分頂級子系統；
2）架構風格選型；
3）開發技術選型；
4）二次開發技術選型；
5）集成技術選型。
5 細化架構設計
細化架構和概念架構的關鍵區別之一是：概念架構沒有設計到“模塊 + 接口”一級，而細化架構必須關注“模塊 + 接口”。
下圖列出了細化架構設計的5個設計視圖、15個設計任務。
· 細化架構要為“需求”而設計。關鍵對比：概念架構設計的輸入是“關鍵需求”、而不是泛泛的所有“需求”。
· 細化架構要在“概念架構”的設計思想下進行。
· “領域模型”，一方面影響着“邏輯架構視圖”的“領域模型設計”，另一方面影響着“數據架構視圖”的“存儲格式設計”。
4.2.6 架構驗證
如有必要，需要進行架構驗證。
架構驗證的輸出成果是“架構原型”。和一般的開發不同，架構原型的開發不是要完美地、無Bug地實現功能，而是在“細化架構”的總體指導下，僅把存在“風險”的那些設計盡早開發出來，然后通過執行測試等手段判斷“風險”是否解決，如下圖所示。
參考：溫昱《軟件架構設計》