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

需求背景

現在的樣子

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

存在問題

事務腳本看到的是零散的數據，而表模型混合了下文要說領域模型和領域服務界限。

1.     兩者都導致了分析和設計的割裂，領域模型只存在于分析中；數據間的內在關系無法通過代碼體現；

2.     兩者都無法有效的實現業務邏輯的具體的差異化和抽象的一致性；導致學習和維護成本的增加；

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

為何要面向對象？

1. 面向對象是自上而下的開發方法；這種方式對于迭代增進式的結構化過程來說成本是最低的；

2. 數據和業務邏輯的綁定性，采用面向對象容易操作和溝通（即實施成本低），同時有助于區分狀態邏輯和任務邏輯；

3. 業務邏輯的差異性，同一個業務邏輯針對差異性數據有區分做法，采用面向對象容易維護； 

什么是領域驅動設計

領域驅動設計的提出是由Eric Evans在其《領域驅動設計》一書提出。實質上是一種由內而外的設計方法，俗話說的先中間（模型和服務）后兩邊（界面，數據庫以及集成）。

領域驅動設計的優勢

傳統的開發方式：基于數據庫的設計開發。數據庫提供的設計模型是表和字段兩種粒度，這兩種粒度有時并不合適于系統設計：

1. 模型的結構化能力

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

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

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

其中，a.fldA = b.fldB 可以稱為關聯條件，而a.fldC=1可以稱作是坐標條件。

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

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

2. 架構的結構化能力

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

這里看看在邏輯設計上，領域模型驅動設計對于架構影響

A. 服務， 模型和模型倉庫（Repository），模型的重建和關聯交由模型倉庫完成，單個數據邏輯交給模型處理（支持泛化）；

B. 測試的好處；

3. 分析和設計的統一

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

4. 其它好處

4.1.采用領域模型可以屏蔽持久化信息。持久化設計的表設計是和DBA相關的，DBA對于表設計有權力的。采用模型可以有效隔離各自工作；

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

領域驅動設計的可能

上下文環境

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

基礎平臺

隨著ORM框架的發展，如hibernate，可以提供繼承多態等能力，能夠支持關聯關系，特別是面向對象設計中生命周期相關的聚合關系，使得基于領域模型開發在技術上具備了可行性。

當前不足

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

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

領域驅動設計的技術分析

概述

整體結構

領域分兩個含義：領域模型，領域服務，業務規則和Repository；其中模型的持久化，重建和關聯交由Repository完成；而單數據邏輯（依賴自身數據信息以及關聯數據）則歸于模型（支持泛化）；服務則關注于任務處理，包括了多個模型處理，以及其它服務的調用。

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

領域模型

概念上，一個領域模型和普通的符合面向對象原則的對象有聲明區別：領域模型是業務意義上，承載了業務數據（可以認為所有領域模型是有狀態對象），從本質上說它直接來源于現實世界，沒有技術層次上的考慮，“符合面向對象原則的對象”是用面向對象方法分析得到的，是基于計算機領域技術的（這樣的對象可以是無狀態的）；但反過來，符合面向對象的對象不一定反映業務領域的模型。

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

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

領域服務

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

領域模型中邏輯僅包括自身生命周期關聯數據的操作，相當于原子操作；只有領域服務則代表完整的服務操作邊界，例如一個領域服務會包含對一個領域模型的三個調用；這一邊界通常也是事務的控制邊界；

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.

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

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給出來一個區分的“business workflow logic”和“領域邏輯”的準則：視具體情況而定，緊密結合領域模型的，可重用度很高的操作可能是領域邏輯，應該放在領域模型里面；比較難重用的控制邏輯方法，特別是可跨越多個領域模型的操作則放在business facade object里面。

業務規則

這里單列出來，很多時候業務規則是附屬在領域服務中的，但在一些特定項目中，業務規則會被單獨維護。

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

2. 產生一些狀態信息，提供給業務人員參考操作（A rule results either in the discovery of new information or a decision about taking action.）。

其它技術問題

應用職責角色分層，必然涉及到兩種對象，一種是用于展示信息的結構——VO（邊界外通過編碼方式使用的），一種是DAO對象。這兩種職責角色對象，嚴格的說不算是業務設計需要關心的。然而卻和系統開發息息相關。而業務設計中的變化導致相關的工作量卻是巨大的。

VO對象是為了集成而存在的；其意義是：1. 保護系統的信息邊界，提供一種結構可以使其它系統或者組件通過編碼方式獲取系統內信息的方式；2. 保護系統的事務邊界，領域對象技術上攜帶著持久化信息，通過VO得以屏蔽。常見的VO對象存在于Web層和Domain層。

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

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

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

針對維護Dao對象而產生成本的一種解決方法是：代碼生成。生成的策略分為兩種環境，開發環境和生產環境。開發環境實時動態生成，可以采用動態代理機制；而生產環境要求性能，采用預編譯生成能力。

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

設計開發

領域模型的四種類型

領域模型可以分為四種類型：

0. 全局常量對象

1. 長生命周期業務對象（類似保單對象）；

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

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

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

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

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

領域模型的級別

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

領域模型的動靜之分

在系統運行期間，被頻繁建立和更新的稱為“動態”，而在較長的一段時間內保持穩定的稱為“靜態”。

通常而言，“動態”的領域模型群通常代表了系統的核心業務對象。而“靜態”的領域模型則在業務上代表了系統的依存關系。

領域模型的分析過程

1. 設計一個貧血的領域模型，包含所有需要被持久化的數據，除了用例顯示要求的和隱式要求的（根據業務分析出需要的輔助數據，主要是特定的控制信息），以及與其它領域模型的關聯關系；

2. 考慮是否支持多態

3. 分析潛在的性能問題，根據需要人為斷開存在的關聯關系；

4. 列出相關的邏輯，利用面向對象設計原則，決定哪些邏輯屬于該領域，并加入該對象模型；

5. 分析是否實現該對象的依賴關系注入。

業務請求對象的虛實之道

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

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

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

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

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

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

    一個可能的持久化方式是：記錄對象路徑及其對應的值；通過自動化的系統掃描，獲取對象路徑結構，以Key和Value的形式記錄在數據庫中，可以避免復雜的持久化處理；

Repository（Dao）的設計開發

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

已知的有三種設計方式：

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

領域服務的設計開發

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

按粒度劃分：

1. 原子服務，業務服務的原子操作；在產品化設計中，該層次服務應該擁有擴展點和參數化能力；

2. 組合服務，封裝業務服務的組合操作；在產品化設計中，擁有參數化，擴展點，事件和集成能力；

3. 還有一類業務服務設計是實現于工作流，該層次邏輯關注于系統集成上；在產品化設計中，該層次應該擁有事件；

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

按事務劃分：

1. 事務服務，事務服務和持久化操作有關，提供事務邊界；通常是聚合服務；

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

由于服務是針對領域，因而事務服務不關注于工作流的流程狀態，只關心相關領域中長生命周期領域模型的生命周期；而計算服務更不關心流程相關，只驗證輸入合法性，做出計算，返回結果，完全是無狀態的；工作流則關心的是相關領域中的request對象的業務狀態，對于同一業務對象的并發處理，應該通過業務來控制；

領域服務的運行模式

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

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