摘要：
概要設計和詳細設計，可能是最開始聽說的設計，但後來發現如果侷限在這兩個設計的框架下，可能會有諸多不順，我們需要架構設計、資料庫設計、模組設計和使用者體驗設計，本文主要分享架構設計，此文有點長，所以分拆為上下兩篇，上篇為你分享：如何避免架構設計”放之四海而皆準“的問題，如何做到”需求驅動架構設計“？
大綱：
1.什麼是優秀的設計？
2.優秀的設計能節省專案工作量
3.優秀設計從分析需求開始
4.軟體系統不是木桶型的
5.軟體設計的“大道理”
6.規劃系統骨架——架構設計
7.打造系統的底蘊——資料庫設計
8.細節決定成敗——詳細設計
9.使用者感覺好才是真的好——使用者體驗設計
10.持續提升設計水平
本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。
6.規劃系統骨架——架構設計
6.1 從概要設計、詳細設計說起
最開始我對概要設計和詳細設計的理解是這樣的：概要設計就是初步的比較粗線條的設計，詳細設計就是詳細的能指導編碼的設計。其實我的這個理解比較“廢”，基本上“概要“和”詳細“這兩個詞囉嗦解釋而已，其實當時沒有見過這兩種設計的實際案例，更加不清楚概要設計和詳細設計的界線在哪。
我剛開始做程式設計師的時候是沒有什麼設計文件的，但有時我會主動寫一些，也沒有什麼格式和模板要求，自己覺得需要就寫而已。後來我們開始要寫概要設計和詳細設計文件了，我們寫這兩個文件不是為了規範化而規範化，而是希望文件能有效果，我們的做法是這樣的：
1）我們參考業界標準和自己的實際情況，制定了概要設計和詳細設計的模板。
2）專案寫設計文件時建議套用模板，但不必侷限於模板的格式；
2）專案寫設計文件時建議套用模板，但不必侷限於模板的格式；
3）概要設計文件是必須有的，而詳細設計文件可由專案組決定是否需要。
我覺得寫規範的設計文件是必要的，不能老是土法煉鋼的模式來開發軟體啊，於是我開始“正式”寫概要設計和詳細設計文件，但是慢慢產生了一些困惑：
1）概要設計要寫到怎樣的程度，確實沒譜，基本上都是“憑感覺”，能規劃出系統的大致架構以及各部分的關係就差不多了。
2）詳細設計是不是描述出關鍵演算法、設計思路就OK了，是否有必要進一步細化到類名、方法名、引數型別呢？文件需要寫得這麼詳細嗎？是不是直接寫程式碼更好呢？
2）詳細設計是不是描述出關鍵演算法、設計思路就OK了，是否有必要進一步細化到類名、方法名、引數型別呢？文件需要寫得這麼詳細嗎？是不是直接寫程式碼更好呢？
3）資料庫設計是概要設計還是詳細設計呢？
4）軟體的外在表現、人機互動的細節、介面風格字型大小等等這些，應該是詳細設計文件要考慮的吧？
漸漸地我們發現不能在侷限在概要設計和詳細設計這兩個概念的框框內，我們覺得軟體專案至少需要四方面的設計，就是：架構設計、資料庫設計、模組設計和使用者體驗設計。
6.2 架構設計、資料庫設計、模組設計和使用者體驗設計
我們先大概看看這四種設計是怎麼回事？
架構設計：近似於概要設計，其實也可以叫“概要設計”，但我覺得“架構設計”這個詞可能更合適。架構設計需要通盤考慮需求後，從巨集觀上規劃系統的各個部分以及各個部分的關係。
資料庫設計：對需求中的業務概念進行系統分析後，設計出表和表關係、檢視等資料庫元素。
模組設計：類似於詳細設計，通常詳細設計是一個文件，但模組設計文件可以有多個。架構設計將系統劃分成多個模組，模組設計就是針對某些或某個模組的具體設計了。
使用者體驗設計：使用者體驗是指使用者使用軟體時的整體感覺，使用者體驗設計需要考慮清楚軟體的整體介面規劃、介面先後關係、文字表達、軟體與使用者如何互動等等。使用者體驗設計是“由頂而下”設計思路重要的第一步！
我做的專案中通常每個專案至少需要1份架構設計文件、1份資料庫設計文件、0到多份模組設計文件和1份使用者體驗設計文件。但需要特別說明是：這四種設計其實不代表四種文件，僅僅是說明了四種型別的設計而已，設計文件的格式和數量是不限的，文件的名字也是沒有規定必須叫什麼的。軟體設計是有無盡的可能性的，不要被文中的說法侷限你的思維。
本篇重點介紹架構設計，其他三種設計請留意後續文章。
6.3 不要“放之四海而皆準”的架構設計
架構設計是從巨集觀上規劃系統的各個部分及各部分的關係，那怎樣表示系統的”各個部分“和“各部分的關係”呢？我們看兩個案例。
案例1 ：用分層架構表示的軟體架構
如下這個圖的表示方法合適嗎？
圖6.1 分層架構
你可能會發現，這個圖不是在前面的系列文章中見過嗎？沒錯，這就是前一篇中出現過的圖。
某一次我作為面試官面試一位應聘軟體設計師崗位的應聘者，我讓他畫圖表示一下他曾經做過的一個專案的架構設計。他當時就畫了一個三層架構的圖給我，不過不是用UML圖，而是用簡單的集合圖形（矩形、圓形、線條等）畫出來。其實不用UML圖畫架構設計也不是很什麼大問題，問題是這樣畫出來的設計是不是太粗了？是不是“放之四海而皆準”？他畫了這個圖後，我跟進問了一些具體的問題，他都沒有能答出來，只能用一些軟體設計的大道理來“招架”，所以我只能認為他軟體設計不具備實際的工作能力了。
圖6.1在前面中出現，是因為我要說明什麼是N層架構，這個圖在前文中是沒有問題的。但如果用這個圖來表示一個具體專案的架構設計，那麼就是等於“廢話”！如果設計文件中僅僅只有類似圖6.1的通用設計圖，這個文件可以扔掉了。
但凡是有例外，某公司的設計文件果然就是這個樣子的，你會發現一個很“神奇”的情況：只有將專案的名字和相關的背景描述改一下，這個設計文件馬上可以成為另外一個專案的設計文件！而專案組們對這個事情樂此不彼，他們非常“欣賞”這樣的設計文件。你會覺得很奇怪，難道這個專案小組是不幹實事，喜歡幹這些沒用的事情？後來我才發現其中奧妙：因為該公司的過程規定專案必須寫設計文件，QA經常來檢查，專案組為了應付這個檢查，就用這個最節省工作量的辦法來應付過去。瞭解真相後，真的是讓人哭笑不得！
分層設計確實是很多系統的設計思路，但在一個具體系統中表示分層設計時就需要表達得更加具體，太抽象就變成“放之四海而皆準”了，我們要避免“一招走天下”。
案例2：部署圖表示的系統架構
圖6.2 部署圖表示的系統架構
為了避免“放之四海而皆準”的問題，我們要求要用部署圖表示系統架構。最開始還挺有新鮮感的，但慢慢我們發現畫出來的圖與圖6.2類似。我們做的系統大部分是“網頁+資料庫”型別的，系統就只有三種機器，分別是：客戶端、Web伺服器和資料庫伺服器，而Web伺服器和資料庫伺服器還往往是同一臺伺服器呢。於是有同事提出：部署圖畫架構設計一點用處都沒有，因為都是一個鬼樣，大同小異而已。確實如如果每個專案的架構設計圖和圖6.2差不多，那麼又犯了“放之四海而皆準”這個問題！架構設計應該如何做呢？下面我們通過實際案例來體會。
6.4 架構設計是考慮“全部需求”後做出來的
我們仍然用考勤系統為案例，不過和前面的要求不同，需求有所調整。
先看看專案背景：
某公司員工人數約100人，領導想做一個系統對員工的外出及請假進行管理，具體需求見用例圖（見後文）。
假定我們不太需要考慮進度、成本的限制，我們的目標是做出一個高價效比的設計。
假定我們不太需要考慮進度、成本的限制，我們的目標是做出一個高價效比的設計。
現在請看需求：
圖6.3 外出請假管理系統的用例圖
圖中紅色虛線框框框住的內容是比較麻煩的，對軟體設計提出了更高的要求。
架構設計需要考慮全部需求，我們要從這些需求當中發現一些設計的關注點，你發現了哪些呢？
發現設計關注點
我將通過兩個圖來分析設計關注點，先看第一個圖：
圖6.4 設計關注點1
我們需要思考全部需求，對不清楚不具體的需求要進一步提問題，思考這些需求的技術解決方案等等。
此圖列出了兩個關注點，紅色邊框框住的部分是第1個關注點，標記上“1”這個符號；而藍色邊框框住的部是第2個關注點，標記上"2"這個符號。
請看第二個圖：
圖6.5 設計關注點2
此圖展示了第3、4個關注點。
實際上設計關注點可能不止4個；也有可能 少於4個，因為你很牛的話，有些技術點已經駕輕就熟了，對於你來說就不是問題。上述兩個圖展示了前文提到的“優秀的設計從分析需求開始”的思路，接下來我們需要進行初步架構設計並且逐步細化這個設計。
6.5 逐步拆解架構設計
6.6 分散式系統與單機系統的架構設計
6.7 架構設計小結
本文是系列文章的其中一篇，要做軟體設計師一點都不簡單啊，請留意後續文章！
如果本文對你有幫助，麻煩點一下“推薦”啦，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟體知識原創基地創辦人