Domain Logic approaches

Transaction Script(事務腳本):

 

　　使用過程來組織業務邏輯，每一個過程處理來自表現層的單個請求。對於很對業務應用來講均可以被看做是一系列事務。業務的一個請求將觸發一系列的業務處理邏輯，而咱們在代碼中一般採用SpringAOP聲明式事務方式將事務控制在業務層的實現類的方法上面，一個請求對應一套業務流程，對應一個事務控制。前面咱們也提到了事物的4個特性中，有一個隔離性表示事務與事務間是相互隔離的，互不影響的。

 

 　　事務腳本將全部這些業務邏輯組織成單個過程，在組織時一般都是考慮的業務邏輯的過程，將業務邏輯按照必定的順序排列執行，而後將事務控制在某一個主方法的入口上，而且在過程當中直接調用數據庫，或者調用數據庫封裝器（如MyBatis、Hibernate等ORM映射框架）。每一個事物都有屬於它本身的事物腳本，這裏的腳本指的是方法。

 

 　　事務腳本比較適合於業務邏輯相對簡單的狀況下，理論上來講，事務控制在3層架構中任何一層都是能夠的，可是咱們一般來講，都是控制在業務層的實現上的。事務腳本是屬於領域邏輯模式中一種，將其置於與其餘處理表現層和數據源層的類相對獨立的類中。若是置於數據源層的類中，會失去事務腳本的控制原則，由於可能只控制了一部分業務邏輯，而其餘的業務邏輯並無控制到。

 

 　　對於事務腳原本說，不少時候都有3個具體的類來構成，他們通常分別是Sevice,Dao,JavaBean, Service類主要用於組織業務邏輯，Dao類主要用於實現數據的存儲，JavaBean主要用於數據的封裝。

 

 　　事務腳本貴在簡單，對於少許邏輯的應用程序來講，它很是實用 。若是業務邏輯複雜時，就會致使事務之間的冗餘代

 

 

Domain Model(域模型):

　

領域模型同時將行爲和數據做爲領域邏輯的核心。所以沒法像事務腳本同樣只關心過程和表面需求，也沒法像表模塊同樣只關心數據。問題終於清晰了：

 

（1）事務腳本模式不（或逃避）深刻分析需求。

 

（2）表模塊強調了數據，得不到充分的領域模型。

 

（3）領域模型模式採用通用語言解決需求問題，採用過程和數據結合解決領域邏輯的組織。

 

 

 

實在是不能說的再複雜了，由於本質上的簡單。因爲領域邏輯自己的特性，每每會產生如下兩種傾向的領域模型：

 

（1）形式上相似事務腳本模式的領域模型，這是因爲領域邏輯自己的特性決定，即便從代碼上看起來十分類似，可是具備更穩定和更少需求變更的優點。

 

（2）形式上相似表模塊模式的領域模型。其餘同上。

 

 

 

優點也是實在太明顯了。我實在不能拒絕。這不是技術上的問題，這是需求分析和模型設計上的問題，我實在不能把這些簡單的概念搞的更復雜了。在使用和不斷完善通用語言的需求分析過程當中，經過屢次深刻分析和迭代咱們獲得了比較穩定的需求分析，在完善設計的過程當中，咱們經過使用和識別出實體、值對象、領域服務和領域事件等概念，劃分出聚合、子域、界限上下文來簡化咱們的設計。這是在以領域邏輯爲核心的前提下，不斷深刻、細化和迭代的天然結果。

 

 

Table Module(表模塊 ):

表模塊再也不將過程做爲組織領域邏輯的核心，而是將數據做爲領域邏輯的核心。一些在深受事務腳本模式的毒害的團隊可能意識到了過程的變化太不可預測了，而每每又不去或不能在需求分析上下功夫，所以從技術角度抓住了業務邏輯中相對過程更穩定的數據部分。也僅此而已。採用表模塊的模式每每有如下兩個結果：

（1）設計的結果主要是E-R圖或披着類圖皮的E-R圖。

（2）天然的採用數據模型但堅持認爲是領域模型。

 

也天然而然的獲得表模塊的適用範圍：

（1）業務邏輯自己就是以數據爲核心的簡單處理。

（2）業務邏輯的流程十分簡單，這點和事務腳本是一致的。