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

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

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

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

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

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

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

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

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

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

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