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

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

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

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

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

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

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

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

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

原文標題：軟件架構要設計到的程度

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