轉載出處：http://www.blogjava.net/AndersLin/archive/2009/05/07/269496.html
作者：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間的集成設計就非常重要。
已知的有三種設計方式：
|
方式 |
描述 |
優缺點 |
|
1. 兩個接口兩個實現類 |
Repository和Dao各自獨立接口，而通過Repository實現類轉發請求給Dao實現類 |
這種方式雖然正統，但是維護成本太高；一次更新最多要改四處地方 |
|
2.兩個接口一個實現類 |
Repository和Dao各自獨立接口，一個實現類同時實現兩個接口 |
這種方式就大大簡化維護成本；一次更新最多隻改一個接口和一個實現類 |
|
3. 兩個接口一個實現類 |
與方式2不同是，Dao接口繼承Repository接口，一個實現類實現Dao接口 |
這種方式的維護成本和方式2差不多，但是當接口方法在這個兩個接口間流動時，可以通過開發工具完成 |
另外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）。這幾個模式處理的各自不同的場景。其中數據流模式很適合需要處理大量數據的情況。