Context
建立架構愿景，為架構的設計定義了主要的設計策略和實現思路。應用分層的原則則對整個的軟件進行了結構上的劃分，并定義了結構的不同部分的職責。而現在，我們需要對初步完成的模型進行必要的改進。
Problem
我們如何對初始架構模型進行改進?
Solution
對模型進行改進的活動可以分為精化和合并兩種。我們先從精化開始。
首先，我們手頭上的初始架構模型已經包括了總原則(參見架構愿景模式)和層結構(參見分層模式)兩部分的內容�，F在我們要做的工作是根據需求和架構原則來劃分不同的粗粒度組件。粗粒度組件來源于分析活動中的業務實體。把具有很強相關性業務實體組合起來，形成一個集合。集合內部存在錯綜復雜的關系，同時集合向外部提供服務接口。這樣的集合就稱為粗粒度組件。粗粒度組件對外的接口和內部的實現是相區分的。粗粒度組件的形式有很多，Java平臺上的Jar文件、Windows平臺上的dll文件，甚至古老的.o或.a文件都可以是粗粒度組件的表現形式。設計優秀的粗粒度組件應該只是完成一項功能，這一點是它與子系統的主要區分。一個系統中可能包括會計子系統、庫存管理子系統。但是提供會計粗粒度組件或是庫存管理粗粒度組件是沒有什么意義的。因為這樣的粗粒度組件的范圍過于廣泛，難以發揮重用的價值。
粗粒度組件是可以(可能也是必須)跨越層次的。粗粒度組件擁有持久化的行為，擁有業務邏輯，需要表示層的支持。這樣看起來，它所屬的軸向和層次的軸向是相互垂直的。
粗粒度組件來源于需求。需求階段產生的需求說明書或是用例模型將是粗粒度組件開發的基礎。在擁有了需求工件之后，我們需要對需求進行功能性的劃分，將需求分為幾個功能組，這樣我們基本上就可以得到相應的粗粒度組件了。如果系統比較龐大，可以對功能組再做細分。這取決于粗粒度組件的范圍。過小的范圍，將會造成粗粒度組件不容易使用，用戶需要理解不同的粗粒度組件之間的復雜關系，最后的結果也將包含大量的組件和復雜的邏輯。過大的范圍，則會造成粗粒度組件難以重用，導致粗粒度組件稱為一個子系統。
假設我們需要開發一個人力資源管理系統。經過整理，它的需求大致分為這樣幾個部分：
組織結構的設計和管理：包括員工職務管理和員工所屬部門的管理。
員工資料的管理：包括員工的基本資料和簡單的考評資料。
日常事務的管理：包括了對員工的考勤管理和工資發放管理。
對于前兩項的功能組，我們認為建立粗粒度組件是比較合適的。但是對于第三項功能組，我們認為范圍過大，因為將之分為考勤管理和工資管理�，F在我們得到了四個粗粒度組件。分別是組織結構組件、員工資料組件、員工考勤組件、員工工資組件。
在得到了粗粒度組件之后，我們的工作需要分為兩個部分：第一個部分是定義不同的粗粒度組件之間的關系。第二個部分是在粗粒度組件的基礎上定義業務實體或是定義細粒度組件。
不同的粗粒度組件之間的關系其實就是前文提到的粗粒度組件的外部接口。如果可能，在粗粒度組件之間定義單向的關聯(如上圖所示)可以有效的減少組件之間的耦合。如果必須要定義雙向的關聯，請確保關聯雙方組件之間的一致性。在上圖中，我們可以清晰的看出，組織結構處于最底層，員工資料依賴于組織結構，包括從組織結構中獲得員工的所屬部門，以及員工職務等信息。而對于考勤、工資組件來說，需要從員工資料中獲取必要的信息，也包括了部門和職務兩方面的信息。這里有兩種關聯定義的方法，一種是讓考勤組件從組織結構組件中獲得部門和職務信息，從員工資料中獲得另外的信息，另一種是如上圖一樣，考勤組件只從員工資料組件中獲得信息，而員工資料組件再使用委托，從組織結構中獲得部門和職務的信息。第二種做法的好處是向考勤、工資組件屏蔽了組織結構組件的存在，并保持了信息獲取的一致性。這里演示的只是組件之間的簡單關系，現實中的關系不可能如此的簡單，但是處理的基本思路是一樣的，就是盡可能簡化組件之間的關系，從而減少它們之間的耦合度。
考慮另一種的需求情況，在原先的系統的基礎上，我們又增加了會計子系統部分，其中的一個粗粒度組件是對部門、員工進行成本分析。在原先的模型基礎上，我們增加了對分層的考慮。從下圖中，我們可以看到，組織結構組件已經發揮了它的重用性，被成本分析組件使用了。從分層上考慮(參見分層模式)，我們將組織結構組件劃分到工具層，而將其它的組件劃分到領域層，并在領域層中進行子系統級的劃分。從某個角度上來說，這種做法類似于一個分析模型的建模過程�？傊�，這個過程中，最重要的就是定義好不同的組件的關系。盡管這中分析是初始的、模糊的。
在得到了粗粒度組件模型之后，我們需要對其進行進一步的分析，以得到細粒度的組件。細粒度的組件具有更好的重用性，并使得架構設計的精化工作更進一步。按Jacobson推薦的面向對象軟件工程(OOSE)的做法，我們需要從軟件的目標領域中識別出關鍵性的實體，或者說是領域中的名詞。例如上例中的員工、部門、工資等。然后決定它們應該歸屬于哪些粗粒度組件。先識別細粒度組件還是先識別粗粒度組件并沒有固定的順序。
最初得到的組件模型可能并不完善，需要對其進行修改�？赡苣硞�組件中的類太多了，過于復雜，我們就需要對其進一步精化、分為更細的組件，也許某個組件中的類太少了，需要和其它的組件進行合并。也許你會發現某兩個組件之間存在重復的要素，可以從中抽取出共性的部分，形成新的組件。組件分析的過程并沒有一種標準的做法，你只能夠根據具體的案例來進行分析。到最后，你可能會為其中的幾個類的歸屬而苦惱不已，不要在它們身上浪費太多的時間，盡善盡美的模型并不存在。
最后的模型將會明確的包含幾個經過精化之后的粗粒度組件。粗粒度組件之間的關系也會進行一次重新定義。如果這時候，粗粒度組件之間仍然存在著復雜的關系，也許意味著你的業務邏輯比較復雜，因此這個部分需要你投入比較多的精力來處理。當然，你可以通過一些技巧來減少不同組件之間的耦合程度。這里有幾種可參考的辦法：
第一種方法是使用外觀(Facade)模式(在分層模式中，我們就提到過外觀模式)。如下圖所示，新引入的BusinessFacade類充當了外觀的角色，將調用者和復雜的業務類隔離了起來，調用者無須知道業務類之間的復雜的關系，就能夠進行業務處理，從而大大降低了調用者和業務類之間的耦合度。這種方法在實踐中經常被采用，適合用在內部關系較為復雜的組件中，也適合用在業務層向表示層發布接口的情況中。對于外觀模式來說，我們可以在BusinessFacade類的業務方法中提供參數，來實現數據的傳遞。這對于一些數據較少的情景特別的適用。如果當數據種類較多時，也可以使用參數類或值類來達到數據傳送的目的。
第二種方法是使用命令(Command)模式，該模式也來自于設計模式一書。在處理參數時，命令模式使用了一系列的set方法來逐一設置參數，最后調用execute()來執行業務邏輯。命令模式的好處是為調用者提供了統一的接口，調用者并不需要關心具體的業務邏輯，他需要做的就是設置數據，并調用execute()方法。如果遇到業務邏輯需要用到較多的參數，逐個的調用set方法過于麻煩了，也可以提供一個setValues()方法來處理多個參數。當然，該模式也有其弱點，如果業務方法太多，那么相應的Command類也會隨之增多。這是我們不希望看到的。
除了上面介紹的兩種方法以外，還可以使用諸如工廠(Factory)模式、業務代表(Business Delegate)模式等方法來減少不同組件之間的耦合度。應該認識到，不同的設計模式有其不同的上下文環境，在架構設計中使用設計模式(以及分析模式)有助于優化設計，但是請注意模式的上下文環境，誤用或濫用模式反而會導致設計的失誤。
以上介紹的方法除了能夠降低不同的組件之間的耦合度之外，還可以起到向調用者隱藏實現的功能。這一點對于重構活動(參見Refactoring模式)非常的關鍵，因為它可以有效的緩解在對組件進行重構時將變化擴散到其它的組件中。
精化是對模型進行改進的第一步。完成的模型基本上代表了最終的軟件。但如果我們對其進行認真的檢查，我們會發現模型仍然存在問題。這時候的問題主要體現在設計模型過于肥大了。如果說精化使得模型變得復雜，那么合并就是使得模型變得簡單。千萬不要以為這兩項工作是互斥的，通過這兩項活動，可以使得模型得到極大的改進。
還記得我們在簡單設計模式中提到的簡單原則嗎?在進入下面的討論之前，請確保你能夠理解簡單原則，這是敏捷的核心原則之一。
在上文中我們提到了一些設計模式的使用，而在整個的敏捷架構設計的文章中，我們也大量地討論了模式。而在很多時候，我們其實是在不恰當的使用模式來解決一些簡單的問題。所以，在使用模式之前，我們應該回顧需求說明書(或是用例模型)上的相關部分，確定是否需要使用模式。
在一次的設計軟件的持久性機制的時候，我選用了DTO(Data Transfer Object)模式作為持久層的實現機制。原因只是我在前一天晚上看了這個模式，并覺得它很酷�？雌饋砦沂欠噶四Ｊ骄C合癥了(當學習了一個模式之后，就想方設法的使用它)。在花費了很多的時間學習并實現該模式之后，我發現該模式并沒能夠發揮它應有的作用。原因是，模式的上下文環境并不適合用在目前的軟件中，原本只需要用JDBC就可以實現的功能，在使用了模式之后，反而變得復雜了。糟糕的是，我不得不向開發人員解釋這個模式，吹捧這個設計模式的精妙之處。但是結果令人不安。開發人員顯然不能夠理解這個模式在這里發揮了什么樣的作用。最后，我去掉了這個模式，設計得到了簡化。
同樣的，在開發過程還存在各種各樣的過度設計的例子，尤其是數據庫訪問、線程安全、一致性等方面的設計。這些問題往往需要花費大量的時間來處理，但是他們的價值卻并不高，尤其是小型的系統。當然，在設計一些大型的系統時，這些問題是必須要考慮的。
而當使用設計模式在對不同的組件進行整合的時候，我們也需要對組件的行為進行合并。將不同組件之間的相同的行為合并到一個組件中，尤其是那些關系非常復雜的組件。這樣可以把復雜的關系隱藏到組件內部，而簡化其對外提供的接口。
很難評判設計是否已經完成了。這里有兩個不同的極端�；ㄙM了過多的時間在初始設計上，以及過度的迭代。在初始模型上花費太多的時間并不一定能夠得到盡善盡美的模型，相反的，可能還會因為設計師鉆牛角尖的行為導致設計模型的失誤。而在過于頻繁的迭代對于改進模型同樣沒有好處，因為實際上，你不是在改進模型，而是在改變模型。請區分這兩種完全不同的行為，雖然它們似乎很相似。在Refactoring模式中，我們還會進一步對迭代和模型改進進行討論。
一種判斷方法是請編碼人員來評判設計是否完成。設計模型最后是要交給編碼人員，指導編碼人員的開發工作的。因此，如果編碼人員無法理解模型，這個模型設計的再好看，也沒有太大的作用。另一方面，如果編碼人員認為模型已經足夠指導開發工作了，那么還有什么必要再畫蛇添足下去了呢?不同水平、不同經驗的編碼人員對模型的要求也不一樣。在我們的工作中，對資深開發人員和開發新手的發布的模型是不一樣的。對于資深的開發人員而言，可能只需要對他說，在組件A和組件B之間使用外觀模式，他就能夠理解這句話的意思，并立即著手開發，可是對于沒有經驗的開發人員，就需要從模式理論開始進行講述。對于他們來說，設計模型必須足夠充分，足夠細致。設置需要把類、方法、參數、功能描述全部設計出來才可以。
復審是避免設計模型出現錯誤的重要手段。強烈建議在架構設計過程中引入復審的活動。復審對于避免設計錯誤有著重大的幫助。復審應該著重于粗粒度組件的分類和粗粒度組件之間的關系。正如后續的Refactoring模式和穩定性模式所描繪的那樣，保持粗粒度組件的穩定性有助于重構行為，有助于架構模型的改進。
(待續)
作者簡介：
林星，辰訊軟件工作室項目管理組資深項目經理，有多年項目實施經驗。辰訊軟件工作室致力于先進軟件思想、軟件技術的應用，主要的研究方向在于軟件過程思想、Linux集群技術、OO技術和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com 和他聯系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
