敏捷面向?qū)ο蠓治雠c設(shè)計思想

萬星

摘要

本文主要討論以面向?qū)ο蟮姆椒▉順?gòu)建企業(yè)信息系統(tǒng)，對比了面向?qū)ο蠼Ｅc面向過程和數(shù)據(jù)建模的區(qū)別，和使用面向?qū)ο蠼５膭訖C(jī)。本文對于面向?qū)ο蠓治雠c設(shè)計中蘊(yùn)含的思想進(jìn)行了一些擴(kuò)展，討論了面向?qū)ο蠹夹g(shù)與REST，Workflow，面向服務(wù)之間的關(guān)系，以及面向?qū)ο蠹夹g(shù)與這些應(yīng)用的關(guān)系。

1       引言

本文建立在企業(yè)級信息系統(tǒng)開發(fā)的前提下，不討論其他類型的計算機(jī)系統(tǒng)，這一點要首先聲明，因為不同訴求不同領(lǐng)域的計算機(jī)工作者總是會對同一問題得到不同的見解，并且爭論一些毫不相干的話題。

企業(yè)信息系統(tǒng)具有以下幾個特點：

1.         需要處理大量相互關(guān)聯(lián)的數(shù)據(jù)。這一特點使得信息系統(tǒng)總是與數(shù)據(jù)庫關(guān)聯(lián)在一起，并促成了早期的以數(shù)據(jù)建模方式開始構(gòu)建信息系統(tǒng)。數(shù)據(jù)庫專家致力于如何設(shè)計數(shù)據(jù)模型，以使訪問高效，不易出錯等。這時，管理數(shù)據(jù)是主要需要解決的問題。這一情況，在現(xiàn)在仍然需要重視。另一方面，這些數(shù)據(jù)之間具有廣泛的聯(lián)系，復(fù)雜的數(shù)據(jù)模型就像一張大網(wǎng)一樣，各個數(shù)據(jù)彼此參照，因此當(dāng)添加、改變或移除一個節(jié)點時都相當(dāng)復(fù)雜。

2.         沒有“邏輯”的業(yè)務(wù)邏輯。業(yè)務(wù)常常缺乏一個具有嚴(yán)格數(shù)學(xué)意義的邏輯，往往會因為與某個客戶的談判，臨時將催款日期推后幾天，而改變了過去的處理邏輯。在企業(yè)應(yīng)用中，正是成千上萬的“一次性業(yè)務(wù)邏輯”導(dǎo)致了開發(fā)的難度[Fowler02]。即使是不經(jīng)常改變的業(yè)務(wù)，也可能會存在大量的針對不同情況的不同的處理邏輯。企業(yè)應(yīng)用如何能正確將變元與恒元分離開，使得變元獨(dú)立于恒元進(jìn)行變化，是構(gòu)建穩(wěn)定的信息系統(tǒng)的主要思想。另外，業(yè)務(wù)流程在某些系統(tǒng)中也是經(jīng)常會改變的，但是其改變的只是操作序列，而推動業(yè)務(wù)流轉(zhuǎn)的元模型并未改變。因此，抽象出了工作流引擎。

3.         復(fù)雜的用戶界面。企業(yè)信息系統(tǒng)往往會帶有一個復(fù)雜的用戶界面，包含大量的控件，對用戶激發(fā)的系統(tǒng)事件進(jìn)行響應(yīng)調(diào)用系統(tǒng)操作。將業(yè)務(wù)邏輯和用戶界面邏輯分開是件非常困難的事情，比如，對于某些數(shù)據(jù)的篩選，雖然看似是用戶界面的一個簡單的選擇，實際上卻蘊(yùn)含著復(fù)雜的業(yè)務(wù)邏輯。另外，需要支持多種客戶端，也是用戶界面處理的難題。

4.         大量的并發(fā)訪問。企業(yè)信息系統(tǒng)往往是一個多用戶并發(fā)訪問的系統(tǒng)，因此必須做好并發(fā)處理，否則就會出現(xiàn)線程爭搶，數(shù)據(jù)庫死鎖，事務(wù)也會因為多種不一致性而失敗。

5.         存在大量的異構(gòu)的遺留系統(tǒng)。有的時候不得不面對拯救信息孤島，整合遺留系統(tǒng)的問題，尤其是在當(dāng)今已經(jīng)出現(xiàn)了大量的企業(yè)信息系統(tǒng)的時候。因此SOA，REST等技術(shù)的出現(xiàn)，成為徹底打破平臺束縛，進(jìn)行異構(gòu)系統(tǒng)整合的首選。

    雖然同屬于軟件開發(fā)，但是信息系統(tǒng)開發(fā)與其它軟件開發(fā)還是有很大區(qū)別的，因此，對于該領(lǐng)域的不同方法，面對不同的情況，發(fā)揮了不同的作用。

面向過程的面對業(yè)務(wù)處理序列建模，而非業(yè)務(wù)中固定的實體及其固有行為。而這些業(yè)務(wù)處理序列會時常發(fā)生變化，也會因為一個不可思議的條件而產(chǎn)生細(xì)微的差異，導(dǎo)致大量重復(fù)的處理代碼或者需要不斷的需要修改已經(jīng)穩(wěn)定發(fā)布的代碼甚至是模塊。比如訂單是ERP系統(tǒng)中常見的實體，而處理訂單的業(yè)務(wù)邏輯則各不相同，面向過程沒有對穩(wěn)定的東西建模而對不穩(wěn)定的東西建模，因此在處理易變的業(yè)務(wù)邏輯是有問題。數(shù)據(jù)建模，是對于業(yè)務(wù)系統(tǒng)中的業(yè)務(wù)實體進(jìn)行建模，然而這些數(shù)據(jù)表缺乏表達(dá)業(yè)務(wù)含義的能力，但是在應(yīng)用早期，對于業(yè)務(wù)處理的需求也比較少，這樣做是什么問題，就是在今天，如果業(yè)務(wù)邏輯簡單或者很固定，則采用這種方法也是沒有問題的。然而，隨著業(yè)務(wù)的復(fù)雜性、多樣性和易變性，特別是對于同一業(yè)務(wù)會存在多種不同的處理情況，僅依靠數(shù)據(jù)建模就不足以完成要求了。

三層架構(gòu)[TK78，Gartner95]是一個清晰的分層架構(gòu)，也是眾多分層架構(gòu)中最著名的一個。表現(xiàn)層，業(yè)務(wù)層和持久化層，形成一個單向依賴層模式，也分離了不同的系統(tǒng)處理關(guān)注點。雖然不同的理論提出了不同的分層架構(gòu)，但是我們都可以通過對于三層架構(gòu)的擴(kuò)展和細(xì)分，去發(fā)現(xiàn)其他層次的意義。

新的技術(shù)帶來了新的解決問題的方案，然而已有的經(jīng)驗如何服務(wù)于這些新的技術(shù)，去解決那些由來已久的問題，或者以傳統(tǒng)的方式去解決新技術(shù)自身的問題，同樣是值得思考的。

1.1    對世界建模的三大方法論

在對于世界建模的方法論中，主要有三種方法占領(lǐng)了高地，分別是結(jié)構(gòu)化方法（面向過程[Yourdon79]），面向?qū)ο蠓缎停蛯嶓w關(guān)系模型（面向數(shù)據(jù)范型）。結(jié)構(gòu)化方法強(qiáng)調(diào)過程序列，面向?qū)ο髲?qiáng)調(diào)對象交互，實體關(guān)系模型強(qiáng)調(diào)實體與其間的關(guān)系，其不關(guān)注業(yè)務(wù)處理，即只是靜態(tài)建模。

1.2    信息系統(tǒng)與三大范型

在開發(fā)企業(yè)級信息系統(tǒng)過程中，我們都要對于業(yè)務(wù)中的概念進(jìn)行建模，無外乎就是業(yè)務(wù)實體（領(lǐng)域模型），業(yè)務(wù)操作（業(yè)務(wù)處理），單據(jù)，被統(tǒng)計的數(shù)據(jù)集，業(yè)務(wù)實體之間有某種關(guān)系（一對多、多對一等關(guān)聯(lián)關(guān)系，特化/泛化的繼承關(guān)系，生命周期同步或異步的包含代表的組合/聚合關(guān)系，一方對另一方調(diào)用或其他行為的依賴關(guān)系），業(yè)務(wù)操作的序列這些概念，而實體或者對象或者結(jié)構(gòu)體都包含字段/屬性/成員變量。而三大方法論只不過是從不同角度觀察和描述世界，因為軟件不能也不必對于世界進(jìn)行完整的建模，因此選擇有利于項目軟件活動的建模方法是必要的，每種方法都各有所長，在過去四十年間，使用各種方法都創(chuàng)建了大量成功的系統(tǒng)和導(dǎo)致了很多失敗的項目。

簡單而言，信息系統(tǒng)主要為了解決業(yè)務(wù)問題，業(yè)務(wù)通過一個個促使?fàn)顟B(tài)發(fā)生變化的操作得以開展，使用結(jié)構(gòu)化方法主要是通過外部力量改變數(shù)據(jù)狀態(tài)，而面向?qū)ο蠓椒ㄊ峭ㄟ^對象自身的行為改變其內(nèi)部狀態(tài)（所謂封裝的概念）。

在這里我將簡單分析一下三大方法是如何對上述業(yè)務(wù)概念進(jìn)行建模的。在結(jié)構(gòu)化方法中，過程是一等公民，我們首先要知道做事情的一連串過程，經(jīng)典的分析工具是業(yè)務(wù)流程圖和數(shù)據(jù)流程圖，此方法更加強(qiáng)調(diào)數(shù)據(jù)的結(jié)構(gòu)，是單數(shù)還是集合。一個過程就是一個改變實體狀態(tài)的操作序列。

在面向?qū)ο笾校瑢ο笫且坏裙瘢覀冎饕P(guān)注的是對象如何通過向彼此發(fā)送消息，支配行為，改變狀態(tài)。很多面向?qū)ο蟮膶Ｖ驼撐亩紡?qiáng)調(diào)了面向?qū)ο蠼Ｊ紫仁菍π袨榻＃浯问菍?shù)據(jù)結(jié)構(gòu)建模，比如責(zé)任驅(qū)動設(shè)計（RDD）[WW89]，契約式編程等。

而在實體關(guān)系模型中，首先要找到實體，然后確定實體和實體之間的關(guān)系。很多開發(fā)者都發(fā)現(xiàn)E-R圖和領(lǐng)域模型圖（通常用UML類圖表示）很相似，甚至分不清數(shù)據(jù)模型和領(lǐng)域模型，這是很正常的，因為它們是對同一個世界進(jìn)行建模。而這些實體/對象都會包括屬性，所以某些模型看上去是相似的了，但是這種相似不等于完全相同，所以才會有諸如對象關(guān)系阻抗不匹配的困擾。實體關(guān)系建模反映了在完成某一業(yè)務(wù)過程時各個實體以及它們之間的關(guān)系的狀態(tài)快照（SnapShot）或者選擇狀態(tài)快照（限定捕捉某些實體的某些字段以及某種特定組合）。這些快照有可能就是業(yè)務(wù)過程中產(chǎn)生的單證或者統(tǒng)計數(shù)據(jù)表中的統(tǒng)計單元。狀態(tài)（State）這個詞在面向?qū)ο蠹夹g(shù)的詞匯表中代表的意思是對象屬性在某一時刻的值集合。從面向?qū)ο蟮慕嵌葋砜矗_發(fā)者需要將這些在刷新（flush）內(nèi)存之后依然需要保存的狀態(tài)持久化到數(shù)據(jù)庫中（或者平面文件（flat file）中，諸如文本文件、XML文件之類的），所以在面向?qū)ο蠓缎椭校瑪?shù)據(jù)庫只是持久化機(jī)制的一種，并非系統(tǒng)的核心，某些順時狀態(tài)只需要保存在內(nèi)存中即可。而以數(shù)據(jù)庫為中心開發(fā)的系統(tǒng)，會傾向于將任何狀態(tài)都持久化到數(shù)據(jù)庫中，比如購物車的不同實現(xiàn)方式，使用面向?qū)ο笤O(shè)計可能會傾向于使用Hashmap，而以數(shù)據(jù)庫為中心則傾向于將其映射到數(shù)據(jù)庫中。

2       面向?qū)ο蠓治雠c設(shè)計

面向?qū)ο蠓治雠c設(shè)計是非常流行的方法，除了流行的設(shè)計模式、設(shè)計原則和最佳實踐之外，其本身的含義則缺乏鮮明的注釋，本節(jié)以ERP系統(tǒng)為例，試圖將其與其他兩種方法論視圖做一下對比。

以另外兩種方式對于領(lǐng)域建模的思維來看ERP系統(tǒng)，看到的就是一個個單據(jù)的填寫與流轉(zhuǎn)（數(shù)據(jù)流程圖），數(shù)據(jù)庫中記錄的變化，統(tǒng)計報表。那么業(yè)務(wù)呢？業(yè)務(wù)就只是填寫單據(jù)和生成報表嗎？系統(tǒng)所做的工作就只是幫助用戶記錄填寫的數(shù)據(jù)，或者僅僅就是支持CRUD操作嗎？

如果以面向?qū)ο笠暯莵矸治觯吹降氖鞘裁茨兀吭谝粋€對象系統(tǒng)中，對象扮演業(yè)務(wù)領(lǐng)域中的角色，彼此發(fā)送消息，完成屬于自己職責(zé)的任務(wù)。

2.1    信息系統(tǒng)中一些常見概念

在這一節(jié)中，主要探討在企業(yè)信息系統(tǒng)中常見的一些概念，在面向?qū)ο笙到y(tǒng)視角下的含義。

[單證]

單證處理是信息系統(tǒng)的主要功能，某些信息系統(tǒng)對于用戶而言就是處理單證，然而就本質(zhì)而言，某些單證是處理業(yè)務(wù)的附屬品，它們本身沒有行為，或者是為了作為執(zhí)行某種操作的依據(jù)（在進(jìn)行某項業(yè)務(wù)時所開理的手續(xù)，如出庫單，合同；進(jìn)行某項業(yè)務(wù)時對照信息，如理貨單），或者是為了長久記錄操作狀態(tài)以備事后查證（收費(fèi)憑證）或統(tǒng)計分析，簡單而言，他們是為業(yè)務(wù)而存在的，并非業(yè)務(wù)本身。這些單據(jù)的特點是，其數(shù)據(jù)都來自于其他領(lǐng)域?qū)ο蠡蛘呒兲摌?gòu)（為了系統(tǒng)得以運(yùn)轉(zhuǎn)而虛構(gòu)出來的對象，而非領(lǐng)域中的對象）[Larman04]，因此它們不是真正的對象。而某些單據(jù)，則是領(lǐng)域中的對象，比如計劃，其不是其他對象狀態(tài)快照的簡單集合，而是具有行為的對象，它代表的抽象意義是對于未來的安排與決策。

[UI]

而用戶界面是什么？在面向?qū)ο蠓治鲋校徊贿^是用戶操縱對象社區(qū)的接口，和展示對象狀態(tài)的接口（或者說是窗口）。另外一個叫做表現(xiàn)層的概念，則又將頁面邏輯和應(yīng)用控制邏輯進(jìn)行分離。為了隱藏客戶端對于對象社區(qū)的知曉，簡化類型轉(zhuǎn)換和異常處理，經(jīng)常會使用VO（值對象）[Fowler2002]搜集領(lǐng)域?qū)ο笾行枰故窘o用戶的狀態(tài)（如Struts中FormBean）。在分布式系統(tǒng)中，會使用其作為DTO（數(shù)據(jù)傳輸對象），如今XML是異構(gòu)系統(tǒng)的一個選項。

使用Delphi，VB等微軟平臺的工具進(jìn)行開發(fā)時，常會使用數(shù)據(jù)感知控件構(gòu)造界面，這意味著不具有一個代表領(lǐng)域概念的對象層，而且傾向于采用對象關(guān)系建模，并且程序常常是過程化的。這在業(yè)務(wù)簡單穩(wěn)定，大多數(shù)操作僅僅是簡單的CRUD操作時這樣做是合理且有效的，然而在大型復(fù)雜的信息系統(tǒng)構(gòu)建過程中，這將不能應(yīng)對系統(tǒng)的變化和擴(kuò)展。

[數(shù)據(jù)庫]

在以對象為中心的信息系統(tǒng)中，會決定將哪些對象進(jìn)行持久化。在這里存在一個問題，持久化的一定是一個定格到某個狀態(tài)的對象，還是對象中的數(shù)據(jù)到數(shù)據(jù)表的一個非面向?qū)ο笥成洹Ｇ罢咄ㄟ^借助O/R映射工具可以實現(xiàn)一個優(yōu)雅的對象持久化層次，而后者會使用一個不完整的對象模型。使用成熟的O/R映射工具可以避免很多對象模型到實體關(guān)系模型映射的困難。不需要使用實體關(guān)系模型再對領(lǐng)域重新建模，而可以采用一個有規(guī)律的轉(zhuǎn)化（比如引用與外鍵的關(guān)系）。

2.2    信息系統(tǒng)構(gòu)建中的面向?qū)ο蠓治?/span>

面向?qū)ο笙到y(tǒng)的穩(wěn)定性保證在于其對于領(lǐng)域的準(zhǔn)確抽象，比如飯店的核心業(yè)務(wù)就是點菜，上菜，結(jié)帳。隨著飯店規(guī)模的擴(kuò)張，各種技術(shù)的發(fā)展，金融規(guī)則的變更，這三個核心的業(yè)務(wù)是不會變的，變的是如何點菜（服務(wù)員記在腦袋里，記在點菜單上，記在手持PDA上，還是顧客自己在點菜單上勾畫，在電子菜單上點擊選擇，這些都只是點菜方式的不同），需要產(chǎn)生哪些憑證（是否打印出來供顧客確認(rèn)，是否需要上菜時進(jìn)行核對，是否需要與后廚核對，是否需要與財務(wù)人員核對，不同的答案組合會得到不同的票據(jù)，其上的內(nèi)容也會有所不同），如何上菜（顧客自取還是服務(wù)員送達(dá)），如何結(jié)帳（飯前結(jié)帳還是飯后結(jié)帳，現(xiàn)金支付，還是未來隨著飯店不斷發(fā)展壯大之后可以采用會員卡結(jié)帳，積分結(jié)帳，信用卡結(jié)帳等多種方式）。面向?qū)ο蠓治鰞?yōu)劣體現(xiàn)為以下幾個方面：

1、是否對于領(lǐng)域有個相對合理的抽象。比如前例，合理的抽象絕對不會是[填寫點菜單]。這需要領(lǐng)域?qū)＜业膮⑴c，因為只有他們最清楚該領(lǐng)域的核心是什么。領(lǐng)域驅(qū)動設(shè)計，建立合理的領(lǐng)域?qū)ο蟊徽J(rèn)為是解決企業(yè)應(yīng)用核心復(fù)雜性之道。[Evans03，Fowler02]

2、是否有效分離表現(xiàn)層，業(yè)務(wù)層和持久層。表現(xiàn)層作為對外提供服務(wù)的接口，指明了外部如何使用該系統(tǒng)的契約，這樣業(yè)務(wù)層可以作為Web Service暴露給外部，可以是REST風(fēng)格的服務(wù)接口，抑或作為另一個系統(tǒng)的數(shù)據(jù)源。而數(shù)據(jù)源層作為業(yè)務(wù)層訪問外部服務(wù)的接口，指明了該系統(tǒng)如何使用其它服務(wù)的契約，這些服務(wù)就可能是數(shù)據(jù)庫服務(wù)，消息服務(wù)，甚至是另一個可以提供數(shù)據(jù)的系統(tǒng)。這也恰恰提醒我們，表現(xiàn)層接口和數(shù)據(jù)源層（我還是覺得叫數(shù)據(jù)訪問層比較好）接口并不直接相關(guān)，因此在設(shè)計時不要將這兩個接口進(jìn)行簡單的設(shè)計映射，表現(xiàn)層接口的契約與數(shù)據(jù)源層接口的契約簡單對應(yīng)會造成系統(tǒng)不穩(wěn)定，數(shù)據(jù)訪問層的變動將導(dǎo)致表現(xiàn)層接口的變動。另外，尤其要記住，它們是為不同目的設(shè)計的！

3、是否有效分離應(yīng)用邏輯與領(lǐng)域邏輯。在大型企業(yè)信息系統(tǒng)中，會分離出單獨(dú)的應(yīng)用邏輯層，以確保領(lǐng)域邏輯的穩(wěn)定和可復(fù)用性。領(lǐng)域邏輯和應(yīng)用邏輯都屬于業(yè)務(wù)邏輯。應(yīng)用邏輯有時被稱為工作流邏輯[Fowler02]。這一分離對于大型信息系統(tǒng)而言是非常重要的，這使得領(lǐng)域模型獨(dú)立于不斷變化的應(yīng)用需求。應(yīng)用需求的例子包括點菜服務(wù)（Order Dishes Service），其中會用到點菜（Order Dishes，只包含創(chuàng)建并將點菜單與支付方式，點菜單項與Dish對象進(jìn)行關(guān)聯(lián)或者解除關(guān)聯(lián)等操作），點菜單（Dishes Order），支付方式（Payment Method），菜單（Menu，其中包含Dish對象）等領(lǐng)域?qū)ο蠛推渲械念I(lǐng)域邏輯（比如點菜單中的添加點菜項目邏輯中，可能會包含合并相同菜項，數(shù)量加1，并更新消費(fèi)總額的領(lǐng)域邏輯），同時還可能包括向其他系統(tǒng)發(fā)送消息等邏輯，如庫存系統(tǒng)，財務(wù)系統(tǒng)。這些領(lǐng)域邏輯會在不同的應(yīng)用需求之下使用，比如老板管理菜單時，同樣會用到菜單對象。而是否通知更新其他系統(tǒng)，或者其它應(yīng)用需求，與領(lǐng)域本質(zhì)并無直接關(guān)系，并且會不斷變更（比如進(jìn)行精細(xì)化庫存管理之前并不需要將點菜與庫存直接關(guān)聯(lián)），因此將其分離是很重要的。需要注意的是，應(yīng)用邏輯與應(yīng)用控制層并非一物，應(yīng)用控制層位于表現(xiàn)層，作用在于接受請求，調(diào)用領(lǐng)域邏輯或者應(yīng)用邏輯，其核心在于實現(xiàn)控制邏輯，在小型信息系統(tǒng)中不存在單獨(dú)的應(yīng)用邏輯層，其中對于領(lǐng)域邏輯的調(diào)配和非領(lǐng)域邏輯的實現(xiàn)也在這一層中完成。在分層結(jié)構(gòu)中，應(yīng)用邏輯會被實現(xiàn)為服務(wù)層中的對象，而在服務(wù)層中，有時則只使用業(yè)務(wù)門面（Facade）模式，門面只是對于領(lǐng)域?qū)ο笠粋€薄層，業(yè)務(wù)邏輯完全存在于領(lǐng)域?qū)ο笾?/span>[Fowler02]。然而無論采用何種分層架構(gòu)或在分層架構(gòu)中的哪一層次實現(xiàn)應(yīng)用邏輯和領(lǐng)域邏輯，對于應(yīng)用邏輯與領(lǐng)域邏輯的分離都是重要的，這比在系統(tǒng)中僅僅分離出業(yè)務(wù)邏輯更進(jìn)了一步。

總之，構(gòu)建一個真正代表領(lǐng)域核心的、合理抽象、職責(zé)明晰的領(lǐng)域模型是保證系統(tǒng)穩(wěn)定發(fā)展的前提。

2.3    業(yè)務(wù)建模方法與用例使用

業(yè)務(wù)建模（在面向?qū)ο蠓治鲋兄附㈩I(lǐng)域模型）和用例使用分別是系統(tǒng)分析工具和需求搜集分析工具。建立領(lǐng)域模型和編寫用例文本是一個交替進(jìn)行的過程。在編寫用例前，開發(fā)人員和領(lǐng)域?qū)＜視黄鸾⒁恍┖诵牡某橄竽Ｐ停缓缶帉懹美ㄖ饕靡园l(fā)現(xiàn)新的需求[Cockburn01]）從而獲得啟發(fā)，擴(kuò)展領(lǐng)域模型。

編寫用例要注意以下幾點：

1.         編寫用例是指編寫用例文本，而非繪制用例圖。用例圖的作用在于說明用例之間的關(guān)系，參與者與用例之間關(guān)系，以及參與者之間的關(guān)系。作為用例文本的高層展示具有一定作用，然而專注于用例關(guān)系會導(dǎo)致沒法專注于對于復(fù)雜靈活的業(yè)務(wù)需求的發(fā)現(xiàn)與捕捉。

2.         要區(qū)分業(yè)務(wù)用例和系統(tǒng)用例。業(yè)務(wù)用例主要描述業(yè)務(wù)流程，可以使用活動圖，業(yè)務(wù)流程圖等技術(shù)加以圖形化表示；系統(tǒng)用例主要描述系統(tǒng)功能，與傳統(tǒng)的功能列表相比，其強(qiáng)化了參與者與系統(tǒng)的交互，并且對于分解多條件事件和異常處理有巨大好處。好的系統(tǒng)用例有助于在業(yè)務(wù)建模時發(fā)現(xiàn)核心抽象，并且對于以用戶故事的形式組織迭代開發(fā)具有指導(dǎo)意義。系統(tǒng)用例可以使用交互圖進(jìn)行圖形化表示。經(jīng)典的結(jié)構(gòu)化方法引入業(yè)務(wù)流程圖以描述業(yè)務(wù)流程，并使用DFD（數(shù)據(jù)流程圖）進(jìn)行細(xì)化，實際上只是完成了業(yè)務(wù)用例的編寫，而對于系統(tǒng)用例則采用功能列表等技術(shù)，用例方法并非是面向?qū)ο蟮模撬顝V泛的被用于面向?qū)ο蠓缎椭小?/span>

3.         編寫用例應(yīng)采用迭代方式。不少組織在瀑布模型中使用用例方法，一次編寫大量用例，并且每個用例都具有大量擴(kuò)展流程，編寫者和審核者都可能因為大段的文字描述而產(chǎn)生疲勞感和抵觸情緒。因此，在每個迭代中只細(xì)化幾個場景（可能是主成功場景或擴(kuò)展場景）即可，同時Larman也指出一次迭代的最小工作單元就是一個場景[Larman04]。對于用例的重構(gòu)也是不可或缺的，隨著對于需求的深入了解，用例也需要不斷更新。比如需要將過于瑣碎的步驟提取成新的用例。

4.         要保持用例中執(zhí)行步驟的抽象程度一致。用例場景中的每個步驟都有可能作為一個引用用例，用例可以被看作一個不斷展開下去的故事[Cockburn01]。因此某些明顯為了某一目標(biāo)而出現(xiàn)的步驟被歸結(jié)為一個引用用例可以保持抽象一致。

5.         注意區(qū)分系統(tǒng)事件和系統(tǒng)操作。系統(tǒng)事件指的是外部輸入事件，參與者發(fā)起系統(tǒng)事件，如按下鼠標(biāo)左鍵；系統(tǒng)操作是指處理系統(tǒng)事件的操作[Larman04]，比如當(dāng)參與者按下鼠標(biāo)左鍵時，系統(tǒng)提示用戶按下鼠標(biāo)左鍵[Ambler02]。

6.         編寫用例參照一個好的格式和遵循一些優(yōu)秀的實踐和模式大有裨益。Cockburn的《編寫有效用例》和另兩位作者的《有效用例模式》值得推薦，尤其是前者幾乎是必讀書籍，其毫不含糊的直擊每個用例初學(xué)者都會遇到的問題，如怎樣處理條件分支，怎樣編寫含有CRUD操作的用例等。

7.         要清楚用例并不是需求的全部。建立詞匯表（可作為數(shù)據(jù)詞典使用），UI需求說明書，業(yè)務(wù)規(guī)則等以記錄其他需求有助于編寫高效的用例[Larman04，Cockburn01]，另外，也有助于發(fā)現(xiàn)真正的業(yè)務(wù)邏輯，而不被UI操作，數(shù)據(jù)存儲策略等需求干擾。

建立領(lǐng)域?qū)ο髮挠美谋荆ㄖ饕窍到y(tǒng)用例）中獲得靈感。主要包括：

1.         發(fā)現(xiàn)對象，確定Role Stereotypes

2.         發(fā)現(xiàn)并分配職責(zé)

有大量優(yōu)秀的著作討論如何發(fā)現(xiàn)對象和分配職責(zé)，其中由RDD（責(zé)任驅(qū)動設(shè)計）的創(chuàng)始人Wirfs-Brock編寫的《對象設(shè)計：角色，責(zé)任和協(xié)作》是對于該問題討論的專著，Larman的《UML和模式應(yīng)用》中提出的GRASP原則（通用職責(zé)分配軟件模式），Ambler的《Object Primer》和McConnel的《代碼大全》中對于職責(zé)分配的討論。

此外對于構(gòu)建企業(yè)信息系統(tǒng)的開發(fā)人員而言，Martin Fowler的《分析模式：可復(fù)用對象模型》和Eric Evans《領(lǐng)域驅(qū)動設(shè)計：企業(yè)應(yīng)用核心復(fù)雜性解決之道》提供了業(yè)務(wù)領(lǐng)域現(xiàn)成的模式和分析問題的方法。

2.4    信息系統(tǒng)構(gòu)建中的面向?qū)ο笤O(shè)計

區(qū)分需求分析、系統(tǒng)分析和系統(tǒng)設(shè)計是非常重要的，Ed Yourdon和Peter Coad的巨著《面向?qū)ο蠓治雠c設(shè)計》明確的劃分了這一點。然而Evans卻強(qiáng)調(diào)要建立一個統(tǒng)一的，貫穿需求分析、系統(tǒng)分析與設(shè)計過程的領(lǐng)域模型，以統(tǒng)一業(yè)務(wù)人員與開發(fā)人員的思想。而在分析模型（即領(lǐng)域模型）與設(shè)計模型之間建立低表示差異具有重要的意義[Larman04]。本文對于分析模型，領(lǐng)域模型，領(lǐng)域?qū)ο螅O(shè)計模型等概念的區(qū)分參照[Larman04]。

與結(jié)構(gòu)化方法相比，面向?qū)ο笤O(shè)計擁有大量的模式，雖然某些模式同樣適用于非面向?qū)ο笤O(shè)計，但是面向?qū)ο蠊逃械哪芰梢愿玫膶嵺`這些模式。

基于建立好的抽象的領(lǐng)域模型進(jìn)行面向?qū)ο笤O(shè)計，使用接口，委托，繼承，多態(tài)等技術(shù)手段分離變化，是面向?qū)ο蠓缎瓦M(jìn)一步實現(xiàn)高穩(wěn)定性、易擴(kuò)展性、高可重用性信息系統(tǒng)的保證。

3       工作流與面向?qū)ο蠹夹g(shù)

3.1    業(yè)務(wù)流程，工作流與業(yè)務(wù)邏輯，業(yè)務(wù)規(guī)則

業(yè)務(wù)流程，工作流，業(yè)務(wù)邏輯，業(yè)務(wù)規(guī)則等概念既相似又不同。在不同規(guī)模的信息系統(tǒng)中，它們所起的作用不盡相同，而在不同的著作中，對于它們的定義也不同。

在大多數(shù)語境下，業(yè)務(wù)流程和工作流是同一概念，某些工作流規(guī)范亦稱為業(yè)務(wù)流程管理規(guī)范，而采用了UML活動圖來定義工作流。

業(yè)務(wù)邏輯表示完成業(yè)務(wù)的邏輯，那些涉眾比較廣，跨越了很多會話，生命周期很長的業(yè)務(wù)邏輯應(yīng)該被歸于業(yè)務(wù)流程，而某些業(yè)務(wù)規(guī)則，亦是業(yè)務(wù)邏輯的一部分。當(dāng)然更多的是介于兩者之間的業(yè)務(wù)邏輯（如前文討論領(lǐng)域邏輯）。

業(yè)務(wù)規(guī)則表示了處理某項業(yè)務(wù)的規(guī)則，可能是企業(yè)內(nèi)部的規(guī)章制度，法律法規(guī)，稅務(wù)規(guī)則等。在企業(yè)信息系統(tǒng)中，經(jīng)常會遇到針對不同類型的產(chǎn)品或客戶，需要基于不同的業(yè)務(wù)規(guī)則進(jìn)行處理的情況。

對于項目所建立的信息系統(tǒng)而言，哪部分是最復(fù)雜的，最多變的，最能產(chǎn)生收益和造成風(fēng)險的，是必須要分析清楚的。

工作流引擎在于將業(yè)務(wù)流程或工作流中的節(jié)點之間的流轉(zhuǎn)或調(diào)用提取出來，構(gòu)建為通用的框架，并將流程定義分離出來，以提高業(yè)務(wù)流程管理的能力。

然而，并不是所有的信息系統(tǒng)的核心復(fù)雜性都來自于業(yè)務(wù)流程的多變和復(fù)雜，而恰恰是復(fù)雜多變的領(lǐng)域邏輯，而改變工作流程的情況并不常見，流程也并不復(fù)雜。

因此，工作流引擎或平臺依然無法解決領(lǐng)域邏輯的復(fù)雜性和易變性，而解決這些問題的強(qiáng)大工具依然是面向?qū)ο蠹夹g(shù)。

3.2    工作流與面向?qū)ο蠹夹g(shù)

工作流引擎可以主要負(fù)責(zé)業(yè)務(wù)流程的調(diào)度，其中的每個節(jié)點，調(diào)用一個業(yè)務(wù)門面中的方法。一個業(yè)務(wù)流程可以代表一個應(yīng)用，比如點餐，可能會涉及到很多參與者，位于不同會話，這往往可能對應(yīng)于一個用例。將應(yīng)用邏輯封裝在較高的層中可以使得變更該層的實現(xiàn)更為容易——你可能用一個工作流引擎就做到這一點[Fowler02]。

把工作流引擎只是看作一個實現(xiàn)應(yīng)用邏輯的框架是有好處的，而某些工作流引擎也是使用面向?qū)ο蠹夹g(shù)實現(xiàn)的。這與前文討論分離應(yīng)用邏輯和領(lǐng)域邏輯是密切相關(guān)的。就前文的例子而言，可以將點菜，更新庫存，通知財務(wù)系統(tǒng)看作是三個節(jié)點，其中前者是人工節(jié)點，后兩者是自動節(jié)點，這樣，添加和修改應(yīng)用邏輯，只需要修改流程定義即可，而不需要修改應(yīng)用邏輯對象（此時整個工作流引擎代替了應(yīng)用邏輯對象）。因此，事務(wù)管理和安全控制也應(yīng)該在這一層次實現(xiàn)。

    這一層次的事務(wù)管理，往往屬于業(yè)務(wù)事務(wù)[Fowler02]，如果像上文一樣設(shè)計，處理起來會更加困難。

節(jié)點的實現(xiàn)方式有很多，某些規(guī)范定義了Web Service，而采取本地方法調(diào)用從效率和編寫測試維護(hù)難度等方面都是更好的選擇。這符合Fowler的分布式對象第一定律：不要分布你的對象[Fowler02]。

工作流平臺和引擎在公文報批，OA中能發(fā)揮最大的作用，而在ERP系統(tǒng)中，只是解決了次要問題，更復(fù)雜的問題依然需要借助面向?qū)ο蠹夹g(shù)，把它作為系統(tǒng)的一個應(yīng)用層在大型復(fù)雜信息系統(tǒng)應(yīng)用中會是一個好的選擇。

然而，如果業(yè)務(wù)流程不會經(jīng)常變更，使用工作流引擎帶來的運(yùn)行效率，事務(wù)處理等問題將使得投入得不償失。

判斷的依據(jù)可以是：繪制活動圖來表示業(yè)務(wù)流程，如果業(yè)務(wù)流程中包含很多節(jié)點，而每個節(jié)點所完成的功能只是簡單的CRUD操作，也不需要處理復(fù)雜多樣的業(yè)務(wù)規(guī)則，則將重點放在工作流引擎上具有重大價值；如果業(yè)務(wù)流程只包含幾個節(jié)點，而每個節(jié)點所要完成的處理非常復(fù)雜，包括復(fù)雜的校驗，計算，關(guān)聯(lián)關(guān)系，需要處理復(fù)雜多樣的業(yè)務(wù)規(guī)則，則應(yīng)該考慮將重點放在對于業(yè)務(wù)規(guī)則的處理上面。

在我們的項目中，我們將屬于不同參與者完成的步驟作為工作流節(jié)點，而由同一個參與者完成的任務(wù)則放到應(yīng)用邏輯對象中，然后以業(yè)務(wù)門面進(jìn)行封裝，以減少離線事務(wù)處理[Fowler02]。由于同時采用遠(yuǎn)程客戶端和Web客戶端，因此我們還會將工作流調(diào)用對象和業(yè)務(wù)門面暴露為遠(yuǎn)程門面，通過使用Spring框架實現(xiàn)遠(yuǎn)程調(diào)用的一致性。