在這里，我們將從一個架構(gòu)師的角度，來說一下架構(gòu)師工作的一個大概流程。當然，架構(gòu)人員的積累，絕不是簡單的幾句就能形容的。

講了軟件架構(gòu)設(shè)計的內(nèi)容與思想、成功架構(gòu)的標準關(guān)鍵與策略，現(xiàn)在大家迫切需要知道的是，按照前面的內(nèi)容已開始了軟件架構(gòu)的設(shè)計之旅，但軟件架構(gòu)究竟需要設(shè)計到什么樣的程度才是符合要求的呢？

在討論這個問題前先看看困擾我們這個問題的軟件架構(gòu)現(xiàn)狀是怎么設(shè)計出來的。拿到軟件需求后，經(jīng)過一翻囫圇吞棗式的通讀(而且是一邊看一邊腦子里飛速的轉(zhuǎn)達：這塊按我的經(jīng)驗應(yīng)該如何實現(xiàn))，然后打開建模工具，根據(jù)需求上提到的幾塊功能模塊要求，畫上幾個用例與時序圖；再從需求中摘下幾個事物建立類，填上類的屬性，又從時序圖中分出幾個函數(shù)方法，最后(基本上想也不用想)根據(jù)經(jīng)驗，依MVC分幾層，套用已有的示例將最近新學的幾個流行的框架添加上去。這就完成了架構(gòu)，不過公司要求寫架構(gòu)設(shè)計文檔，所以又翻出架構(gòu)設(shè)計文檔模板，發(fā)現(xiàn)還少了幾部分內(nèi)容。不要緊，一邊寫一邊看別人的文檔是怎么寫的，依葫蘆畫瓢。評審了，打開文檔或模型，指著用例圖、時序圖幾乎是按需求文檔解釋了一遍：你看系統(tǒng)包括這些功能，每個功能是這樣一步步完成的。什么？這就是軟件需求文檔拷貝過來的？你沒有看到系統(tǒng)分層了嗎？不是選擇了框架嗎？什么？這一層/模塊與下一層模塊是怎樣通訊的、有什么參數(shù)、按什么格式？這不是到了偽代碼級了嗎？不是還有詳細設(shè)計嗎？架構(gòu)設(shè)計把這些都定義出來，還要詳細設(shè)計做什么？架構(gòu)設(shè)計需要詳細到這種地步嗎？你們是評審員，你說的不管對不對都有理，按你說的我進行改一下。評審員，你看一下文檔改得符合你的要求嗎？哪兒不行你說，我按你說的寫，或者你寫一篇樣板我仿著寫？幾經(jīng)周折，評審人員疲備了，老板急了，怎么架構(gòu)設(shè)計超時這么久了還在改？架構(gòu)人員訴苦：我都架構(gòu)設(shè)計完成了，評審人員老說不行，我以前本來沒有這么規(guī)范過，又不知道評審人員心中的架構(gòu)文檔究竟應(yīng)寫到什么程度才算合格。老板找到評審人員：你看工期這么緊，他們也沒有寫過這么規(guī)范的文檔，只要架構(gòu)設(shè)計完成了就行了，或者一邊開發(fā)一邊補文檔？結(jié)果許多影響全局的設(shè)計決策本應(yīng)由架構(gòu)設(shè)計來完成，卻紡統(tǒng)統(tǒng)留到了后邊，最終到了大規(guī)模并行開發(fā)時才發(fā)現(xiàn)，不得不由程序員臨時碰頭決定"將就一下"。

大家不要笑，說我過于夸張了。這是我在一家公司負責過程改進與質(zhì)量保證時的真實情況。我個人認為，軟件架構(gòu)必須設(shè)計達到以下四個必須、一個不一定：

首先，軟件架構(gòu)是用來溝通的，軟件架構(gòu)必須滿足軟件項目所有步眾代表都有自己立場與視角的模型、文檔說明，且這些模型文檔說明僅清晰包含自己立場與視角關(guān)注與有關(guān)的事物，不能有任何遺漏，也最好不要有多余。

其次，軟件架構(gòu)的每一步都是決策過程，而且關(guān)鍵需求決定架構(gòu)，軟件架構(gòu)必須充分清楚地表達出這些決策與決策理由。眾多的需求中為什么這些需求是關(guān)鍵需求？為滿足這些關(guān)鍵需求，采用了什么樣的關(guān)鍵機制、核心技術(shù)與第三方框架？什么選擇這些關(guān)鍵機制、核心技術(shù)與第三方框架而不選用其它的？為什么說它們是可行的？

再則，軟件架構(gòu)必須為以后的開發(fā)提供足夠的指導與限制，因此軟件架構(gòu)必須確定系統(tǒng)各元素間的關(guān)系、職責、交互接口與協(xié)作機制。僅僅劃出幾個層與層中包含的元素而不約束它們間的關(guān)系、職責、交互接口與協(xié)作機制，就如同一個公司，它的組織結(jié)構(gòu)圖就掛在墻上——再清晰不過了，但如果接口不清、機制不明，來了任務(wù)、出了事情不清楚找誰、如何匯報、怎樣處理。

然后，軟件架構(gòu)必須突出強調(diào)通信機制、持久化機制和消息機制等公用模塊的深入設(shè)計。通信機制、持久化機制和消息機制等公用模塊較多的涉及軟件的不同部分之間的交互，對系統(tǒng)的功能實現(xiàn)、非功能滿足等成功因素起著舉足輕重的作用。

最后，由于軟件項目的不同、開發(fā)組織結(jié)構(gòu)的不同、開發(fā)團隊情況的不同，軟件架構(gòu)的設(shè)計粒度是不一定的。比如，航天航空領(lǐng)域中的軟件系統(tǒng)對系統(tǒng)的可靠性等質(zhì)量屬性要求非常高甚至可以認為是荷刻，這種情況下對架構(gòu)的設(shè)計詳細程度的要求也會比較高；象IBM這樣的大的團隊中又有小的團隊共同開發(fā)，架構(gòu)的設(shè)計粒度到子系統(tǒng)級就足夠了，各個小團隊精通的技術(shù)各不相同，可以讓其對子系統(tǒng)采用敏捷開發(fā)，對縮短工期、人盡其材有好處；有類似項目經(jīng)驗或項目團隊所有成員整體技術(shù)水平較高的團隊架構(gòu)粒度可適當粗獷，而分布團隊或涉及外包的情況則更強調(diào)架構(gòu)的明確性。總之，架構(gòu)設(shè)計對軟件的不同部分的設(shè)計程度不應(yīng)是整齊劃一的，特別是具體的業(yè)務(wù)功能模塊在架構(gòu)設(shè)計中往往設(shè)計程度不深。

原文標題：軟件架構(gòu)要設(shè)計到的程度

鏈接：http://www.cnblogs.com/seaskycheng/archive/2009/12/06/1617950.html