敏捷思維: 架構設計中的方法學(xué)(11)

精化和合并

級別: 初級

林星, 項目經(jīng)理, 辰訊軟件工作室

2002 年 11 月 01 日

對于一個(gè)已經(jīng)初步建立好的模型（分析模型或是設計模型）來(lái)說(shuō)，對其進(jìn)行精化和合并是必要的步驟。

Context

建立架構愿景，為架構的設計定義了主要的設計策略和實(shí)現思路。應用分層的原則則對整個(gè)的軟件進(jìn)行了結構上的劃分，并定義了結構的不同部分的職責。而現在，我們需要對初步完成的模型進(jìn)行必要的改進(jìn)。

Problem

我們如何對初始架構模型進(jìn)行改進(jìn)？

Solution

對模型進(jìn)行改進(jìn)的活動(dòng)可以分為精化和合并兩種。我們先從精化開(kāi)始。

首先，我們手頭上的初始架構模型已經(jīng)包括了總原則（參見(jiàn)架構愿景模式）和層結構（參見(jiàn)分層模式）兩部分的內容?，F在我們要做的工作是根據需求和架構原則來(lái)劃分不同的粗粒度組件。粗粒度組件來(lái)源于分析活動(dòng)中的業(yè)務(wù)實(shí)體。把具有很強相關(guān)性業(yè)務(wù)實(shí)體組合起來(lái)，形成一個(gè)集合。集合內部存在錯綜復雜的關(guān)系，同時(shí)集合向外部提供服務(wù)接口。這樣的集合就稱(chēng)為粗粒度組件。粗粒度組件對外的接口和內部的實(shí)現是相區分的。粗粒度組件的形式有很多，Java平臺上的Jar文件、Windows平臺上的dll文件，甚至古老的.o或.a文件都可以是粗粒度組件的表現形式。設計優(yōu)秀的粗粒度組件應該只是完成一項功能，這一點(diǎn)是它與子系統的主要區分。一個(gè)系統中可能包括會(huì )計子系統、庫存管理子系統。但是提供會(huì )計粗粒度組件或是庫存管理粗粒度組件是沒(méi)有什么意義的。因為這樣的粗粒度組件的范圍過(guò)于廣泛，難以發(fā)揮重用的價(jià)值。

粗粒度組件是可以（可能也是必須）跨越層次的。粗粒度組件擁有持久化的行為，擁有業(yè)務(wù)邏輯，需要表示層的支持。這樣看起來(lái)，它所屬的軸向和層次的軸向是相互垂直的。

粗粒度組件來(lái)源于需求。需求階段產(chǎn)生的需求說(shuō)明書(shū)或是用例模型將是粗粒度組件開(kāi)發(fā)的基礎。在擁有了需求工件之后，我們需要對需求進(jìn)行功能性的劃分，將需求分為幾個(gè)功能組，這樣我們基本上就可以得到相應的粗粒度組件了。如果系統比較龐大，可以對功能組再做細分。這取決于粗粒度組件的范圍。過(guò)小的范圍，將會(huì )造成粗粒度組件不容易使用，用戶(hù)需要理解不同的粗粒度組件之間的復雜關(guān)系，最后的結果也將包含大量的組件和復雜的邏輯。過(guò)大的范圍，則會(huì )造成粗粒度組件難以重用，導致粗粒度組件稱(chēng)為一個(gè)子系統。

假設我們需要開(kāi)發(fā)一個(gè)人力資源管理系統。經(jīng)過(guò)整理，它的需求大致分為這樣幾個(gè)部分：

• 組織結構的設計和管理：包括員工職務(wù)管理和員工所屬部門(mén)的管理。
• 員工資料的管理：包括員工的基本資料和簡(jiǎn)單的考評資料。
• 日常事務(wù)的管理：包括了對員工的考勤管理和工資發(fā)放管理。

對于前兩項的功能組，我們認為建立粗粒度組件是比較合適的。但是對于第三項功能組，我們認為范圍過(guò)大，因為將之分為考勤管理和工資管理?，F在我們得到了四個(gè)粗粒度組件。分別是組織結構組件、員工資料組件、員工考勤組件、員工工資組件。

在得到了粗粒度組件之后，我們的工作需要分為兩個(gè)部分：第一個(gè)部分是定義不同的粗粒度組件之間的關(guān)系。第二個(gè)部分是在粗粒度組件的基礎上定義業(yè)務(wù)實(shí)體或是定義細粒度組件。

不同的粗粒度組件之間的關(guān)系其實(shí)就是前文提到的粗粒度組件的外部接口。如果可能，在粗粒度組件之間定義單向的關(guān)聯(lián)（如上圖所示）可以有效的減少組件之間的耦合。如果必須要定義雙向的關(guān)聯(lián)，請確保關(guān)聯(lián)雙方組件之間的一致性。在上圖中，我們可以清晰的看出，組織結構處于最底層，員工資料依賴(lài)于組織結構，包括從組織結構中獲得員工的所屬部門(mén)，以及員工職務(wù)等信息。而對于考勤、工資組件來(lái)說(shuō)，需要從員工資料中獲取必要的信息，也包括了部門(mén)和職務(wù)兩方面的信息。這里有兩種關(guān)聯(lián)定義的方法，一種是讓考勤組件從組織結構組件中獲得部門(mén)和職務(wù)信息，從員工資料中獲得另外的信息，另一種是如上圖一樣，考勤組件只從員工資料組件中獲得信息，而員工資料組件再使用委托，從組織結構中獲得部門(mén)和職務(wù)的信息。第二種做法的好處是向考勤、工資組件屏蔽了組織結構組件的存在，并保持了信息獲取的一致性。這里演示的只是組件之間的簡(jiǎn)單關(guān)系，現實(shí)中的關(guān)系不可能如此的簡(jiǎn)單，但是處理的基本思路是一樣的，就是盡可能簡(jiǎn)化組件之間的關(guān)系，從而減少它們之間的耦合度。

考慮另一種的需求情況，在原先的系統的基礎上，我們又增加了會(huì )計子系統部分，其中的一個(gè)粗粒度組件是對部門(mén)、員工進(jìn)行成本分析。在原先的模型基礎上，我們增加了對分層的考慮。從下圖中，我們可以看到，組織結構組件已經(jīng)發(fā)揮了它的重用性，被成本分析組件使用了。從分層上考慮（參見(jiàn)分層模式），我們將組織結構組件劃分到工具層，而將其它的組件劃分到領(lǐng)域層，并在領(lǐng)域層中進(jìn)行子系統級的劃分。從某個(gè)角度上來(lái)說(shuō)，這種做法類(lèi)似于一個(gè)分析模型的建模過(guò)程?？傊?，這個(gè)過(guò)程中，最重要的就是定義好不同的組件的關(guān)系。盡管這中分析是初始的、模糊的。

在得到了粗粒度組件模型之后，我們需要對其進(jìn)行進(jìn)一步的分析，以得到細粒度的組件。細粒度的組件具有更好的重用性，并使得架構設計的精化工作更進(jìn)一步。按Jacobson推薦的面向對象軟件工程（OOSE）的做法，我們需要從軟件的目標領(lǐng)域中識別出關(guān)鍵性的實(shí)體，或者說(shuō)是領(lǐng)域中的名詞。例如上例中的員工、部門(mén)、工資等。然后決定它們應該歸屬于哪些粗粒度組件。先識別細粒度組件還是先識別粗粒度組件并沒(méi)有固定的順序。

最初得到的組件模型可能并不完善，需要對其進(jìn)行修改?？赡苣硞€(gè)組件中的類(lèi)太多了，過(guò)于復雜，我們就需要對其進(jìn)一步精化、分為更細的組件，也許某個(gè)組件中的類(lèi)太少了，需要和其它的組件進(jìn)行合并。也許你會(huì )發(fā)現某兩個(gè)組件之間存在重復的要素，可以從中抽取出共性的部分，形成新的組件。組件分析的過(guò)程并沒(méi)有一種標準的做法，你只能夠根據具體的案例來(lái)進(jìn)行分析。到最后，你可能會(huì )為其中的幾個(gè)類(lèi)的歸屬而苦惱不已，不要在它們身上浪費太多的時(shí)間，盡善盡美的模型并不存在。

最后的模型將會(huì )明確的包含幾個(gè)經(jīng)過(guò)精化之后的粗粒度組件。粗粒度組件之間的關(guān)系也會(huì )進(jìn)行一次重新定義。如果這時(shí)候，粗粒度組件之間仍然存在著(zhù)復雜的關(guān)系，也許意味著(zhù)你的業(yè)務(wù)邏輯比較復雜，因此這個(gè)部分需要你投入比較多的精力來(lái)處理。當然，你可以通過(guò)一些技巧來(lái)減少不同組件之間的耦合程度。這里有幾種可參考的辦法：

第一種方法是使用外觀(guān)（Facade）模式（在分層模式中，我們就提到過(guò)外觀(guān)模式）。如下圖所示，新引入的BusinessFacade類(lèi)充當了外觀(guān)的角色，將調用者和復雜的業(yè)務(wù)類(lèi)隔離了起來(lái)，調用者無(wú)須知道業(yè)務(wù)類(lèi)之間的復雜的關(guān)系，就能夠進(jìn)行業(yè)務(wù)處理，從而大大降低了調用者和業(yè)務(wù)類(lèi)之間的耦合度。這種方法在實(shí)踐中經(jīng)常被采用，適合用在內部關(guān)系較為復雜的組件中，也適合用在業(yè)務(wù)層向表示層發(fā)布接口的情況中。對于外觀(guān)模式來(lái)說(shuō)，我們可以在BusinessFacade類(lèi)的業(yè)務(wù)方法中提供參數，來(lái)實(shí)現數據的傳遞。這對于一些數據較少的情景特別的適用。如果當數據種類(lèi)較多時(shí)，也可以使用參數類(lèi)或值類(lèi)來(lái)達到數據傳送的目的。

第二種方法是使用命令（Command）模式，該模式也來(lái)自于設計模式一書(shū)。在處理參數時(shí)，命令模式使用了一系列的set方法來(lái)逐一設置參數，最后調用execute()來(lái)執行業(yè)務(wù)邏輯。命令模式的好處是為調用者提供了統一的接口，調用者并不需要關(guān)心具體的業(yè)務(wù)邏輯，他需要做的就是設置數據，并調用execute()方法。如果遇到業(yè)務(wù)邏輯需要用到較多的參數，逐個(gè)的調用set方法過(guò)于麻煩了，也可以提供一個(gè)setValues()方法來(lái)處理多個(gè)參數。當然，該模式也有其弱點(diǎn)，如果業(yè)務(wù)方法太多，那么相應的Command類(lèi)也會(huì )隨之增多。這是我們不希望看到的。

除了上面介紹的兩種方法以外，還可以使用諸如工廠(chǎng)（Factory）模式、業(yè)務(wù)代表（Business Delegate）模式等方法來(lái)減少不同組件之間的耦合度。應該認識到，不同的設計模式有其不同的上下文環(huán)境，在架構設計中使用設計模式（以及分析模式）有助于優(yōu)化設計，但是請注意模式的上下文環(huán)境，誤用或濫用模式反而會(huì )導致設計的失誤。

以上介紹的方法除了能夠降低不同的組件之間的耦合度之外，還可以起到向調用者隱藏實(shí)現的功能。這一點(diǎn)對于重構活動(dòng)（參見(jiàn)Refactoring模式）非常的關(guān)鍵，因為它可以有效的緩解在對組件進(jìn)行重構時(shí)將變化擴散到其它的組件中。

精化是對模型進(jìn)行改進(jìn)的第一步。完成的模型基本上代表了最終的軟件。但如果我們對其進(jìn)行認真的檢查，我們會(huì )發(fā)現模型仍然存在問(wèn)題。這時(shí)候的問(wèn)題主要體現在設計模型過(guò)于肥大了。如果說(shuō)精化使得模型變得復雜，那么合并就是使得模型變得簡(jiǎn)單。千萬(wàn)不要以為這兩項工作是互斥的，通過(guò)這兩項活動(dòng)，可以使得模型得到極大的改進(jìn)。

還記得我們在簡(jiǎn)單設計模式中提到的簡(jiǎn)單原則嗎？在進(jìn)入下面的討論之前，請確保你能夠理解簡(jiǎn)單原則，這是敏捷的核心原則之一。

在上文中我們提到了一些設計模式的使用，而在整個(gè)的敏捷架構設計的文章中，我們也大量地討論了模式。而在很多時(shí)候，我們其實(shí)是在不恰當的使用模式來(lái)解決一些簡(jiǎn)單的問(wèn)題。所以，在使用模式之前，我們應該回顧需求說(shuō)明書(shū)（或是用例模型）上的相關(guān)部分，確定是否需要使用模式。

在一次的設計軟件的持久性機制的時(shí)候，我選用了DTO（Data Transfer Object）模式作為持久層的實(shí)現機制。原因只是我在前一天晚上看了這個(gè)模式，并覺(jué)得它很酷?？雌饋?lái)我是犯了模式綜合癥了（當學(xué)習了一個(gè)模式之后，就想方設法的使用它）。在花費了很多的時(shí)間學(xué)習并實(shí)現該模式之后，我發(fā)現該模式并沒(méi)能夠發(fā)揮它應有的作用。原因是，模式的上下文環(huán)境并不適合用在目前的軟件中，原本只需要用JDBC就可以實(shí)現的功能，在使用了模式之后，反而變得復雜了。糟糕的是，我不得不向開(kāi)發(fā)人員解釋這個(gè)模式，吹捧這個(gè)設計模式的精妙之處。但是結果令人不安。開(kāi)發(fā)人員顯然不能夠理解這個(gè)模式在這里發(fā)揮了什么樣的作用。最后，我去掉了這個(gè)模式，設計得到了簡(jiǎn)化。

同樣的，在開(kāi)發(fā)過(guò)程還存在各種各樣的過(guò)度設計的例子，尤其是數據庫訪(fǎng)問(wèn)、線(xiàn)程安全、一致性等方面的設計。這些問(wèn)題往往需要花費大量的時(shí)間來(lái)處理，但是他們的價(jià)值卻并不高，尤其是小型的系統。當然，在設計一些大型的系統時(shí)，這些問(wèn)題是必須要考慮的。

而當使用設計模式在對不同的組件進(jìn)行整合的時(shí)候，我們也需要對組件的行為進(jìn)行合并。將不同組件之間的相同的行為合并到一個(gè)組件中，尤其是那些關(guān)系非常復雜的組件。這樣可以把復雜的關(guān)系隱藏到組件內部，而簡(jiǎn)化其對外提供的接口。

很難評判設計是否已經(jīng)完成了。這里有兩個(gè)不同的極端?；ㄙM了過(guò)多的時(shí)間在初始設計上，以及過(guò)度的迭代。在初始模型上花費太多的時(shí)間并不一定能夠得到盡善盡美的模型，相反的，可能還會(huì )因為設計師鉆牛角尖的行為導致設計模型的失誤。而在過(guò)于頻繁的迭代對于改進(jìn)模型同樣沒(méi)有好處，因為實(shí)際上，你不是在改進(jìn)模型，而是在改變模型。請區分這兩種完全不同的行為，雖然它們似乎很相似。在Refactoring模式中，我們還會(huì )進(jìn)一步對迭代和模型改進(jìn)進(jìn)行討論。

一種判斷方法是請編碼人員來(lái)評判設計是否完成。設計模型最后是要交給編碼人員，指導編碼人員的開(kāi)發(fā)工作的。因此，如果編碼人員無(wú)法理解模型，這個(gè)模型設計的再好看，也沒(méi)有太大的作用。另一方面，如果編碼人員認為模型已經(jīng)足夠指導開(kāi)發(fā)工作了，那么還有什么必要再畫(huà)蛇添足下去了呢？不同水平、不同經(jīng)驗的編碼人員對模型的要求也不一樣。在我們的工作中，對資深開(kāi)發(fā)人員和開(kāi)發(fā)新手的發(fā)布的模型是不一樣的。對于資深的開(kāi)發(fā)人員而言，可能只需要對他說(shuō)，在組件A和組件B之間使用外觀(guān)模式，他就能夠理解這句話(huà)的意思，并立即著(zhù)手開(kāi)發(fā)，可是對于沒(méi)有經(jīng)驗的開(kāi)發(fā)人員，就需要從模式理論開(kāi)始進(jìn)行講述。對于他們來(lái)說(shuō)，設計模型必須足夠充分，足夠細致。設置需要把類(lèi)、方法、參數、功能描述全部設計出來(lái)才可以。

復審是避免設計模型出現錯誤的重要手段。強烈建議在架構設計過(guò)程中引入復審的活動(dòng)。復審對于避免設計錯誤有著(zhù)重大的幫助。復審應該著(zhù)重于粗粒度組件的分類(lèi)和粗粒度組件之間的關(guān)系。正如后續的Refactoring模式和穩定性模式所描繪的那樣，保持粗粒度組件的穩定性有助于重構行為，有助于架構模型的改進(jìn)。