敏捷思維－ 架構設計中的方法學——源自需求

關鍵字：敏捷思維 架構設計 源自需求我們說，和重型方法偏重于計劃、過程和中間產物不同，敏捷方法更加看重人和溝通。人和溝通永遠是第一位的，而計劃、過程和中間產物，那只是保證溝通、實現目標的手段。這并不是說計劃、過程、中間產物不重要，只是不能夠本末倒置 

注：我們把中間產物定義為為了實現跨邊界的溝通而制定的文檔、模型、代碼。例如設計文檔、數據模型等。參考RUP的Artifact。 

評判軟件成功的標準有很多，對于敏捷方法論來說，成功的標準首先在于交付可用的軟件。為了保證軟件的可用性，最重要的就是做好需求。做好需求的方法有很多（參見拙作需求的實踐），但這并不是我們討論的主題。對于我們要開始的架構設計的工作來說，從需求出發來設計架構，這就是保證軟件可用性的一個基本的保證。 

Context 

我們如何開始我們的架構設計工作？ 

Problem 

我們在進行架構設計的時候，往往主要考慮的都是平臺、語言、開發環境、數據庫等一些基本問題，可是對于和客戶的具體情況密切相關的一些問題卻很少系統的考慮。甚至還存在一種誤區，認為架構設計無非就是寫一些空話，套話。這樣子做出來架構設計，如何用于指導軟件的實現呢？ 

IT界的技術層出不窮，面對著如此之多的技術、平臺、框架、函數庫，我們如何選擇一組適合軟件的技術？ 

每一個客戶的軟件都有自身的特點，如何才能夠設計出符合客戶利益的架構？ 

軟件中往往都充斥著眾多的問題，在一開始就把所有的問題都想清楚往往很難做到，但是如果不解決問題，風險又居高不下。 

Solution 

針對需求設計架構。 

架構設計就是鋪設軟件的主管道（例1）。我們根據什么來制定主管道的粗細、路徑等因素呢？很明顯，是根據城市的人口、地理位置、水源等因素來決定的。對應到軟件設計也是一樣的。城市的各因素就是軟件中的各種需求：功能需求、非功能需求、變化案例等等。 

一般來說，功能需求決定業務架構、非功能需求決定技術架構，變化案例決定架構的范圍。需求方面的知識告訴我們，功能需求定義了軟件能夠做些什么。我們需要根據業務上的需求來設計業務架構，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了一些性能、效率上的一些約束、規則。而我們的技術架構要能夠滿足這些約束和規則。變化案例是對未來可能發生的變化的一個估計，結合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個架構的范圍。 

從例2中，我們看到自已字處理軟件的幾種需求的范例。真正的字處理軟件要復雜的多。而我們最主要的就是必須認識到，架構是來自于需求的。有什么樣的需求就有什么樣的架構。試想一下，如果我們沒有對速度的要求，我們還需要考慮這方面的設計嗎？我們上面提到了幾種類型的需求對架構的影響，其實還有一個很重要的需求，就是環境的需求。這并不是一個很重要的需求，但是對于部署（deployment）架構設計來說就特別重要。畢竟，我們開發出的軟件是要上"戰場"的，充分的考慮部署問題是非常有必要的。 

例1：城市中自來水管的架設是一項非常的復雜的工程。為了需要滿足每家每戶的需要，自來水管組成了一個龐大的網絡。在這樣一個復雜的網絡中，如何完成鋪設的任務呢。一般的做法是，先找出問題的根源，也就是水的源頭。從水源鋪設一條管道通至城市，然后根據城市的區域劃分，設計出主管道，剩下的就是使用的問題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來水網絡龐大復雜。但是真正的主管道的非常簡單的。

例2：我們打算開發一個字處理軟件，功能需求可以簡單概括為格式化用戶輸入的文字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不能低于10S，變化案例可能是推出多種語言版本。那么我們在設計業務架構的時候，我們會集中于如何表示文字、圖象、媒體等要素，我們該需要有另外的技術架構來處理速度問題，比如緩沖技術，對于變化案例，我們也要考慮相應的架構，比如把字體獨立于程序包的設計。

原文轉自：http://www.kjueaiud.com