作者：anders小明
2009年5月7日 

需求背景

現(xiàn)在的樣子

如PoEAA中提到的：事務(wù)腳本(Transaction Script)和表模型（Table Moduel）模式。

存在問題

事務(wù)腳本看到的是零散的數(shù)據(jù)，而表模型混合了下文要說領(lǐng)域模型和領(lǐng)域服務(wù)界限。

1.     兩者都導(dǎo)致了分析和設(shè)計的割裂，領(lǐng)域模型只存在于分析中；數(shù)據(jù)間的內(nèi)在關(guān)系無法通過代碼體現(xiàn)；

2.     兩者都無法有效的實現(xiàn)業(yè)務(wù)邏輯的具體的差異化和抽象的一致性；導(dǎo)致學習和維護成本的增加；

3.     兩者都帶來了測試上困難，增加了開發(fā)成本；

為何要面向?qū)ο螅?/span>

1. 面向?qū)ο笫亲陨隙碌拈_發(fā)方法；這種方式對于迭代增進式的結(jié)構(gòu)化過程來說成本是最低的；

2. 數(shù)據(jù)和業(yè)務(wù)邏輯的綁定性，采用面向?qū)ο笕菀撞僮骱蜏贤ǎ磳嵤┏杀镜停瑫r有助于區(qū)分狀態(tài)邏輯和任務(wù)邏輯；

3. 業(yè)務(wù)邏輯的差異性，同一個業(yè)務(wù)邏輯針對差異性數(shù)據(jù)有區(qū)分做法，采用面向?qū)ο笕菀拙S護； 

什么是領(lǐng)域驅(qū)動設(shè)計

領(lǐng)域驅(qū)動設(shè)計的提出是由Eric Evans在其《領(lǐng)域驅(qū)動設(shè)計》一書提出。實質(zhì)上是一種由內(nèi)而外的設(shè)計方法，俗話說的先中間（模型和服務(wù)）后兩邊（界面，數(shù)據(jù)庫以及集成）。

領(lǐng)域驅(qū)動設(shè)計的優(yōu)勢

傳統(tǒng)的開發(fā)方式：基于數(shù)據(jù)庫的設(shè)計開發(fā)。數(shù)據(jù)庫提供的設(shè)計模型是表和字段兩種粒度，這兩種粒度有時并不合適于系統(tǒng)設(shè)計：

1. 模型的結(jié)構(gòu)化能力

1.1. 同一組件下的設(shè)計優(yōu)勢，一個模型可以來自多張表的數(shù)據(jù)聚合而成，一張表可以聚合多個模型；一個邏輯是由幾個固定字段或者非固定字段聚合；模型間的關(guān)聯(lián)關(guān)系也是使用表無法展示的——外鍵的約束對于系統(tǒng)開發(fā)來說實在太有限了。而這些不論表還是字段粒度都無法支持的。

這里強調(diào)一下模型間的關(guān)聯(lián)關(guān)系，特別是和生命周期相關(guān)的聚合和組合關(guān)系。關(guān)系數(shù)據(jù)庫中所保存的是系統(tǒng)分解后的表示，即關(guān)系被分解了而不是被表達了，外鍵對數(shù)據(jù)關(guān)系只起到一種約束作用，它對于查詢語句的構(gòu)建并沒有直接的影響。所有數(shù)據(jù)之間的關(guān)系都必須在查詢的時候明確指定出來，即調(diào)用者必須擁有數(shù)據(jù)關(guān)系的知識，而不是數(shù)據(jù)本身擁有這些知識．在如下的SQL語句中

“select * from a, b where a.fldA = b.fldB and a.fldC = 1 and b.fldD = 2”

其中，a.fldA = b.fldB 可以稱為關(guān)聯(lián)條件，而a.fldC=1可以稱作是坐標條件。

SQL的復(fù)雜性很大程度上來源于我們頻繁的需要在各處指定完全一樣的關(guān)聯(lián)條件而無法把它們抽象成可復(fù)用的組分．在ORM所提供的對象空間中，對象之間的兩兩關(guān)聯(lián)只要指定一次，就可以在增刪改查等各種操作過程中起到作用，特別是在對象查詢語句中，可以通過兩兩關(guān)聯(lián)自動推導(dǎo)出多實體之間的關(guān)聯(lián)關(guān)系，雖然推導(dǎo)出的結(jié)果未必是最優(yōu)化的.

1.2. 采用模型方式容易解決項目的集成問題（兩個組件訪問同一張表的情況）

2. 架構(gòu)的結(jié)構(gòu)化能力

事務(wù)腳本直接訪問到表。換句話說，其架構(gòu)只有服務(wù)+數(shù)據(jù)庫表，這樣的架構(gòu)下數(shù)據(jù)庫表可以說就是我們的模型。

這里看看在邏輯設(shè)計上，領(lǐng)域模型驅(qū)動設(shè)計對于架構(gòu)影響

A. 服務(wù)， 模型和模型倉庫（Repository），模型的重建和關(guān)聯(lián)交由模型倉庫完成，單個數(shù)據(jù)邏輯交給模型處理（支持泛化）；

B. 測試的好處；

3. 分析和設(shè)計的統(tǒng)一

溝通的問題，客戶關(guān)注于其業(yè)務(wù)，分析的模型接近于客戶需求，設(shè)計也采用模型的方式，避免分析和設(shè)計的割裂。有助于開發(fā)人員間，開發(fā)人員和業(yè)務(wù)人員以及客戶間的溝通

4. 其它好處

4.1.采用領(lǐng)域模型可以屏蔽持久化信息。持久化設(shè)計的表設(shè)計是和DBA相關(guān)的，DBA對于表設(shè)計有權(quán)力的。采用模型可以有效隔離各自工作；

4.2. 模型可以通過很多的手段透明的解決性能問題，而采用表做模型導(dǎo)致容易導(dǎo)致性能問題，當然不是沒有辦法解決，一種是通過DataSet的方式，但這樣的切換成本較高。

領(lǐng)域驅(qū)動設(shè)計的可能

上下文環(huán)境

領(lǐng)域模型存在于系統(tǒng)的各個地方，不過在不同地方有不同的映射實現(xiàn)。在通常的開發(fā)過程中，該映射存在于文檔和開發(fā)人員的腦海中的。當要向客戶展示時，就面臨一個映射的關(guān)系。比如要允許客戶可以在線編輯頁面呈現(xiàn)的顯示元素，在規(guī)則定義里使用對象系統(tǒng)時。

基礎(chǔ)平臺

隨著ORM框架的發(fā)展，如hibernate，可以提供繼承多態(tài)等能力，能夠支持關(guān)聯(lián)關(guān)系，特別是面向?qū)ο笤O(shè)計中生命周期相關(guān)的聚合關(guān)系，使得基于領(lǐng)域模型開發(fā)在技術(shù)上具備了可行性。

當前不足

不過ORM在集合上的處理不盡如人意。受限于JDK的集合，不能像DLinq那樣提供集合的過濾和集合函數(shù)操作。使得一些設(shè)計，不得不屈從于性能問題，把領(lǐng)域模型的關(guān)聯(lián)關(guān)系人為斷開。

Ferrum項目或許會是一個可行的方案。

領(lǐng)域驅(qū)動設(shè)計的技術(shù)分析

概述

整體結(jié)構(gòu)

領(lǐng)域分兩個含義：領(lǐng)域模型，領(lǐng)域服務(wù)，業(yè)務(wù)規(guī)則和Repository；其中模型的持久化，重建和關(guān)聯(lián)交由Repository完成；而單數(shù)據(jù)邏輯（依賴自身數(shù)據(jù)信息以及關(guān)聯(lián)數(shù)據(jù)）則歸于模型（支持泛化）；服務(wù)則關(guān)注于任務(wù)處理，包括了多個模型處理，以及其它服務(wù)的調(diào)用。

如果把一個系統(tǒng)看作是一個機械組件的話，那么領(lǐng)域模型就相當于人的骨架；而流程邏輯相當于骨架上的肌肉；那么控制邏輯就相當于肌肉中的神經(jīng)。

領(lǐng)域模型

概念上，一個領(lǐng)域模型和普通的符合面向?qū)ο笤瓌t的對象有聲明區(qū)別：領(lǐng)域模型是業(yè)務(wù)意義上，承載了業(yè)務(wù)數(shù)據(jù)（可以認為所有領(lǐng)域模型是有狀態(tài)對象），從本質(zhì)上說它直接來源于現(xiàn)實世界，沒有技術(shù)層次上的考慮，“符合面向?qū)ο笤瓌t的對象”是用面向?qū)ο蠓椒ǚ治龅玫降模腔谟嬎銠C領(lǐng)域技術(shù)的（這樣的對象可以是無狀態(tài)的）；但反過來，符合面向?qū)ο蟮膶ο蟛灰欢ǚ从硺I(yè)務(wù)領(lǐng)域的模型。

技術(shù)上，領(lǐng)域模型是指那些包含需要被透明持久化的屬性，以及相關(guān)業(yè)務(wù)邏輯的POJO。一個領(lǐng)域模型包含了這些需要被持久化的業(yè)務(wù)數(shù)據(jù)，同時還包含了與之相關(guān)所有業(yè)務(wù)操作（即能操作所有屬于本模型生命周期內(nèi)的模型數(shù)據(jù)），并且有自己的繼承體系。Martin Fowler認為有了這些就可以稱為是一個領(lǐng)域模型，因此在其PoEAA中的ORM包含了一些不透明的持久化方案。我認為一個真正的領(lǐng)域模型需要一個透明持久化。

注： 領(lǐng)域模型在不同視圖下導(dǎo)致不同的內(nèi)容。比如一個代理人Agent對象，在Party的視圖下只擁有基本屬性，而在Sale channel視圖下就保存了一些額外信息如：考核記錄，優(yōu)秀率等。

領(lǐng)域服務(wù)

領(lǐng)域服務(wù)包含的商業(yè)邏輯包含了兩部分：流程邏輯。業(yè)務(wù)領(lǐng)域的流程邏輯（即業(yè)務(wù)流程）。指一系列的業(yè)務(wù)行為，包括維護一個或者多個領(lǐng)域模型。領(lǐng)域服務(wù)是一個Unit Of Work模式。

領(lǐng)域模型中邏輯僅包括自身生命周期關(guān)聯(lián)數(shù)據(jù)的操作，相當于原子操作；只有領(lǐng)域服務(wù)則代表完整的服務(wù)操作邊界，例如一個領(lǐng)域服務(wù)會包含對一個領(lǐng)域模型的三個調(diào)用；這一邊界通常也是事務(wù)的控制邊界；

Rod Johnson在《J2EE without EJB》第10章《持久化》里面比較清楚的論述了這個問題：

Workflow methods at the business facade level are still responsible for transaction demarcation, for retrieving persistent objects in the first place, and for operations that span multiple objects, but no longer for domain logic that really belongs to the domain model.

這段話明白無誤的講清楚了領(lǐng)域模型應(yīng)該包含什么邏輯，不應(yīng)該包含什么邏輯。領(lǐng)域模型包含的邏輯，這里稱之為“領(lǐng)域邏輯”，這些領(lǐng)域邏輯應(yīng)該最小化的依賴于DAO，而我們討論的那些需要持久化操作參與的事務(wù)性邏輯，這里稱之為“workflow methods”，這些“workflow methods”應(yīng)該放在“business facade”，而不應(yīng)該放在領(lǐng)域模型里面。

What logic to put into domain classes versus what to put into workflow controllers should be decided case by case. Operations that are reusable across multiple use case s should normally be part of domain classes. Single use case that are hardly reusable are candidates for controller methods; so are operations that span multiple domain objects.

最后Rod Johnson給出來一個區(qū)分的“business workflow logic”和“領(lǐng)域邏輯”的準則：視具體情況而定，緊密結(jié)合領(lǐng)域模型的，可重用度很高的操作可能是領(lǐng)域邏輯，應(yīng)該放在領(lǐng)域模型里面；比較難重用的控制邏輯方法，特別是可跨越多個領(lǐng)域模型的操作則放在business facade object里面。

業(yè)務(wù)規(guī)則

這里單列出來，很多時候業(yè)務(wù)規(guī)則是附屬在領(lǐng)域服務(wù)中的，但在一些特定項目中，業(yè)務(wù)規(guī)則會被單獨維護。

1. 產(chǎn)生一些控制信息，限制或者觸發(fā)某些行為的執(zhí)行（A rule is a declarative statement that applies logic or computation to information values）；

2. 產(chǎn)生一些狀態(tài)信息，提供給業(yè)務(wù)人員參考操作（A rule results either in the discovery of new information or a decision about taking action.）。

其它技術(shù)問題

應(yīng)用職責角色分層，必然涉及到兩種對象，一種是用于展示信息的結(jié)構(gòu)——VO（邊界外通過編碼方式使用的），一種是DAO對象。這兩種職責角色對象，嚴格的說不算是業(yè)務(wù)設(shè)計需要關(guān)心的。然而卻和系統(tǒng)開發(fā)息息相關(guān)。而業(yè)務(wù)設(shè)計中的變化導(dǎo)致相關(guān)的工作量卻是巨大的。

VO對象是為了集成而存在的；其意義是：1. 保護系統(tǒng)的信息邊界，提供一種結(jié)構(gòu)可以使其它系統(tǒng)或者組件通過編碼方式獲取系統(tǒng)內(nèi)信息的方式；2. 保護系統(tǒng)的事務(wù)邊界，領(lǐng)域?qū)ο蠹夹g(shù)上攜帶著持久化信息，通過VO得以屏蔽。常見的VO對象存在于Web層和Domain層。

因此，VO對象的存在只是為了集成而存在，其是否存在的取決于兩個方面1. 集成的設(shè)計結(jié)構(gòu)；2. 框架的兩個能力——對象路徑訪問能力以及事務(wù)邊界管理。

Domain層VO對象，通常是用于不同領(lǐng)域組件間的交互，但隨著架構(gòu)的改進，集成代碼獨立存在而不再嵌入到組件內(nèi)部，組件的邊界問題保護不復(fù)存在；更進一步的是，框架提供自動化的接口適配映射能力的增強。因而VO對象失去存在的意義。

Web層VO對象，以SWF為例，早在SWF 1.x時代，框架就提供了豐富的對象路徑訪問能力，但其Web交互是典型的MVC2方式，事務(wù)邊界在view的render前關(guān)閉，因而導(dǎo)致需要特定的VO對象來避免持久化信息問題；而SWF 2.x時代，view的render是在事務(wù)邊界內(nèi)，VO不再需要。

針對維護Dao對象而產(chǎn)生成本的一種解決方法是：代碼生成。生成的策略分為兩種環(huán)境，開發(fā)環(huán)境和生產(chǎn)環(huán)境。開發(fā)環(huán)境實時動態(tài)生成，可以采用動態(tài)代理機制；而生產(chǎn)環(huán)境要求性能，采用預(yù)編譯生成能力。

另外Web層或者UI層，不需要額外的VO對象的另一個理由是：通常Web層的獨立維護的成本大于其復(fù)用的價值。在開發(fā)中，Web層需要的信息都來自Domain層，這樣容易出現(xiàn)Web層的VO對象和Domain對象結(jié)構(gòu)一致，雖然這樣便于學習和簡化開發(fā)，但導(dǎo)致維護成本的提高，每當頁面需要一個新的屬性就需要改變太多的類，同時Domain對象設(shè)計容易限制于Web層，而實踐中Web層的變化更多于Domain層。正確的路徑是很好的維護Domain層，同時不維護Web層。

設(shè)計開發(fā)

領(lǐng)域模型的四種類型

領(lǐng)域模型可以分為四種類型：

0. 全局常量對象

1. 長生命周期業(yè)務(wù)對象（類似保單對象）；

2. 交易過程的事務(wù)對象，幾乎沒有生命周期的；

3. 業(yè)務(wù)請求對象和業(yè)務(wù)反饋對象。這類對象以前沒有識別的，通常和VO混在一起；但是在IAA中以及電信業(yè)的模型是這類對象是獨立存在，并被持久化的；業(yè)務(wù)請求對象建立在增量更新上很有用。當然他們也是幾乎沒有生命周期的。

    并非所有的業(yè)務(wù)系統(tǒng)都擁有這四類對象！相當一部分的業(yè)務(wù)系統(tǒng)，并沒有顯著的長生命周期對象，因而沒有明確的增量變更操作類型及其規(guī)則，業(yè)務(wù)操作是直接更新業(yè)務(wù)對象，也就沒有業(yè)務(wù)請求以及業(yè)務(wù)反饋對象；同時此類業(yè)務(wù)系統(tǒng)的事務(wù)對象也通常不存在；

這里要額外補充說明的是：

對于業(yè)務(wù)請求，每個業(yè)務(wù)請求必需記錄下業(yè)務(wù)時間；對于業(yè)務(wù)處理，每個業(yè)務(wù)處理還可能保留一定的人工干預(yù)控制信息，也將同生命周期的輸入數(shù)據(jù)一起記錄；對于生命周期，每個生命周期狀態(tài)的變化都可能會有獨立的數(shù)據(jù)需要記錄。

領(lǐng)域模型的級別

不論是那種類型對象，都擁有一個屬性，對象等級；對于保險系統(tǒng)來說，保單對象，產(chǎn)品對象以及組織對象是一級對象，而險種和角色等都是二級對象，其生命周期附屬于一級對象；這點對于設(shè)計Repository以及服務(wù)粒度都有影響。

領(lǐng)域模型的動靜之分

在系統(tǒng)運行期間，被頻繁建立和更新的稱為“動態(tài)”，而在較長的一段時間內(nèi)保持穩(wěn)定的稱為“靜態(tài)”。

通常而言，“動態(tài)”的領(lǐng)域模型群通常代表了系統(tǒng)的核心業(yè)務(wù)對象。而“靜態(tài)”的領(lǐng)域模型則在業(yè)務(wù)上代表了系統(tǒng)的依存關(guān)系。

領(lǐng)域模型的分析過程

1. 設(shè)計一個貧血的領(lǐng)域模型，包含所有需要被持久化的數(shù)據(jù)，除了用例顯示要求的和隱式要求的（根據(jù)業(yè)務(wù)分析出需要的輔助數(shù)據(jù)，主要是特定的控制信息），以及與其它領(lǐng)域模型的關(guān)聯(lián)關(guān)系；

2. 考慮是否支持多態(tài)

3. 分析潛在的性能問題，根據(jù)需要人為斷開存在的關(guān)聯(lián)關(guān)系；

4. 列出相關(guān)的邏輯，利用面向?qū)ο笤O(shè)計原則，決定哪些邏輯屬于該領(lǐng)域，并加入該對象模型；

5. 分析是否實現(xiàn)該對象的依賴關(guān)系注入。

業(yè)務(wù)請求對象的虛實之道

業(yè)務(wù)請求的概念，與HTTP請求是不同的。為避免誤解，特意加上業(yè)務(wù)一詞修飾。所謂虛實是指是否將業(yè)務(wù)請求概念實例化。不做實例化的理由時處理簡單；實例化則有助于處理業(yè)務(wù)事務(wù)控制以及應(yīng)用賬目模式。一個業(yè)務(wù)操作上的業(yè)務(wù)請求可能包括多個請求對象，與核心業(yè)務(wù)對象對應(yīng)，例如：在線訂單，就包括了購買物品及其數(shù)量和折扣，支付協(xié)議和發(fā)貨協(xié)議等。

對于沒有實例化業(yè)務(wù)請求的情況下，在實際業(yè)務(wù)操作時，對每一個HTTP表單的操作都需要一個物理的事務(wù)來支持。這樣做的問題是，由于沒有記錄業(yè)務(wù)請求，直接操作業(yè)務(wù)對象，在做業(yè)務(wù)日志時只能記錄操作前以及操作后的信息（既“減肥前，減肥后”）；同時跨越多個物理事務(wù)，要支持查詢到一次業(yè)務(wù)請求所有操作的信息，需要新建一個日志索引或者類似的手段，在業(yè)務(wù)開始時獲取注冊一個索引，所有日志操作中引用這個索引，在業(yè)務(wù)結(jié)束后關(guān)閉該索引。雖然如此，也帶來的是業(yè)務(wù)上做回退（undo）以及重做（redo）操作的不便。

但是如果實例化業(yè)務(wù)請求，就很容易處理這兩樣操作。建立一個業(yè)務(wù)請求，同時記錄所涉及的請求數(shù)據(jù)。這樣做的好處是：可以很容易的記錄一些額外的信息；同時可以很容易的支持審批操作（既俗話說的“管帳的不管錢，管錢的不管帳”）。

另外，業(yè)務(wù)請求對象附加好處是，由于某個領(lǐng)域模塊的增量操作通常從一個根對象（即一級對象）開始，所依賴的過濾條件可以從業(yè)務(wù)請求中加以識別并通過框架提前加載，而領(lǐng)域服務(wù)對象的方法接受傳遞對象而不再關(guān)心對象的加載工作；同時也可以通過框架處理基本數(shù)據(jù)復(fù)制工作，這樣程序只關(guān)心關(guān)聯(lián)對象的操作。

業(yè)務(wù)請求對象比較適合明確增量變化的業(yè)務(wù)系統(tǒng)，通常這樣業(yè)務(wù)系統(tǒng)在處理變更時，規(guī)則和關(guān)聯(lián)處理很多；對于全量數(shù)據(jù)，采用業(yè)務(wù)請求對象得不償失，最終兩個對象設(shè)計會趨于一致；對于不確定性變化系統(tǒng)，如果應(yīng)用業(yè)務(wù)請求對象會導(dǎo)致捕獲變化數(shù)據(jù)的困難，應(yīng)該考慮采用更好的業(yè)務(wù)組織方式（如SpringSide的設(shè)計實現(xiàn)，但SS沒有考慮批改的流程和日志）。

不過目前大部分的系統(tǒng)都沒有處理業(yè)務(wù)請求實例化，不是所有的業(yè)務(wù)操作需要審批，另外實例化的麻煩是，已經(jīng)處理了一個日志對象，再處理一個業(yè)務(wù)請求對象總是讓人多少心里有點不爽；

    一個可能的持久化方式是：記錄對象路徑及其對應(yīng)的值；通過自動化的系統(tǒng)掃描，獲取對象路徑結(jié)構(gòu)，以Key和Value的形式記錄在數(shù)據(jù)庫中，可以避免復(fù)雜的持久化處理；

Repository（Dao）的設(shè)計開發(fā)

Repository是一種特殊的Service，不做任務(wù)處理；而是提供模型的持久化，重建和查詢工作。由于企業(yè)應(yīng)用大都通過數(shù)據(jù)庫實現(xiàn)持久化，因而Repository和傳統(tǒng)的Dao間的集成設(shè)計就非常重要。

已知的有三種設(shè)計方式：

另外Dao實現(xiàn)類也是工作中開發(fā)維護成本較高的一部分，可以通過代碼生成降低開發(fā)成本。已知的是JDBC 4.0規(guī)范和iBatis 3.0的實踐。

領(lǐng)域服務(wù)的設(shè)計開發(fā)

    業(yè)務(wù)服務(wù)是整個領(lǐng)域設(shè)計中另一個重要的元素；業(yè)務(wù)服務(wù)的如何設(shè)計，并無定論，但有原則和分類，最重要的是圍繞著業(yè)務(wù)流程設(shè)計，而其基礎(chǔ)建立于底層模型自身業(yè)務(wù)邏輯的原子操作。

按粒度劃分：

1. 原子服務(wù)，業(yè)務(wù)服務(wù)的原子操作；在產(chǎn)品化設(shè)計中，該層次服務(wù)應(yīng)該擁有擴展點和參數(shù)化能力；

2. 組合服務(wù)，封裝業(yè)務(wù)服務(wù)的組合操作；在產(chǎn)品化設(shè)計中，擁有參數(shù)化，擴展點，事件和集成能力；

3. 還有一類業(yè)務(wù)服務(wù)設(shè)計是實現(xiàn)于工作流，該層次邏輯關(guān)注于系統(tǒng)集成上；在產(chǎn)品化設(shè)計中，該層次應(yīng)該擁有事件；

實際上，原子服務(wù)和組合服務(wù)的粒度劃分并不具備可操作性；只不過加以標識試圖進一步的分析，并為產(chǎn)品化設(shè)計做基礎(chǔ)；

按事務(wù)劃分：

1. 事務(wù)服務(wù)，事務(wù)服務(wù)和持久化操作有關(guān)，提供事務(wù)邊界；通常是聚合服務(wù)；

2. 計算服務(wù)，也算是read-only的事務(wù)服務(wù)；計算服務(wù)的粒度不一定；

由于服務(wù)是針對領(lǐng)域，因而事務(wù)服務(wù)不關(guān)注于工作流的流程狀態(tài)，只關(guān)心相關(guān)領(lǐng)域中長生命周期領(lǐng)域模型的生命周期；而計算服務(wù)更不關(guān)心流程相關(guān)，只驗證輸入合法性，做出計算，返回結(jié)果，完全是無狀態(tài)的；工作流則關(guān)心的是相關(guān)領(lǐng)域中的request對象的業(yè)務(wù)狀態(tài)，對于同一業(yè)務(wù)對象的并發(fā)處理，應(yīng)該通過業(yè)務(wù)來控制；

領(lǐng)域服務(wù)的運行模式

簡單的說，業(yè)務(wù)處理將被細化成處理控制器和具體處理器。在這級別，處理對于請求的響應(yīng)處理已知的有三種模式：

事件模式（Observer Pattern）、職責鏈模式（Chain of responsibility Pattern）以及數(shù)據(jù)流模式（Pipes and Filters Pattern）。這幾個模式處理的各自不同的場景。其中數(shù)據(jù)流模式很適合需要處理大量數(shù)據(jù)的情況。