企業應用架構模式中明確提出了三種領域邏輯組織模式：事務腳本、領域模型和表模塊。不少人看的雲里霧里的，不少人說的似懂非懂的，主要原因是沒有從項目的級別的分析和設計經驗，只有單個項目模塊的開發經驗的人很難理解到位。
1.事務腳本：
事務腳本的理解其實最簡單，但是很多人說不清，覺得比領域模型還難理解，也對應不到代碼。但這只是幻覺，怎么可能最簡單的領域邏輯模式都不懂，反而對最復雜的領域模型模式懂了呢。
我們看企業應用架構模式中強調的一句話"使用過程來組織領域邏輯"，其實事務腳本就是從過程的角度看待需求，需求方和開發方在此階段都熱衷的核心是"這個功能是怎么個過程"，二者達成一致后用代碼去將這個粗糙的過程模擬出來。所以大多數人都在不自覺的應用事務腳本模式。簡單說就是使用過程化的代碼在模擬用戶表面的需求。如果這個項目繼續進行下去，那么問題來了：
（1）用戶自己都不太清楚需求，需求肯定會隨着用戶的想法變化而不斷變化。即使你作為需求方如果不仔細思考，只是簡單的陳述下表面的流程，你也會經常性的由於自己偶爾的深入考慮或更沒譜的想法而不斷的變更需求。
（2）事務腳本模式的代碼是過程式的，需要什么調用什么，常見的數據源通信、郵件服務、應用級別的日志安全等各種代碼都混合在一起，如果需求變了，調整起來很困難。
這就是很多項目的一般狀態，因為問題的根源在沒有深入分析和理解用戶的需求，所以不是用什么框架和分層，搞一些似是而非的實體或者采用了IOC和AOP等技術實現能起作用的的。還是要從根源上尋求解決之道，因此領域驅動設計強調通用語言，這樣才能同需求人員一起對具體的領域進行深入的分析，這樣的需求分析和模型設計具有更高的穩定性，才不會因為需求方的腦抽和風暴導致需求頻發大幅度變化。
一旦你了解了事務腳本模式的核心，你就十分清楚事務腳本的適用范圍：
（1）領域邏輯本身就是多個簡單過程。
（2）需求十分簡單，即使看起來表面化也已經足夠深入。
在此提醒大家，要學習領域驅動設計千萬別跑偏，不要忘記領域邏輯本身才是一切的分析和設計的根源。尤其是初學者千萬不要把非領域層和應用層的各種框架技術和組件之類的混入到學習中。在分析和設計的過程中，至少要堅持兩點：
（1）不要在此時關注表示層和數據源層
（2）盡量多從項目整體的角度看待問題，不要只以開發者的角度去思考。
事務腳本依然可以使用各種技術和框架，但無論你怎么命名文件和使用什么組件，依然是以過程來組織業務邏輯。以事務腳本模式組織領域邏輯的設計結果必然是以一系列的流程圖為核心。
2.表模塊：
表模塊不再將過程作為組織領域邏輯的核心，而是將數據作為領域邏輯的核心。一些在深受事務腳本模式的毒害的團隊可能意識到了過程的變化太不可預測了，而往往又不去或不能在需求分析上下功夫，因此從技術角度抓住了業務邏輯中相對過程更穩定的數據部分。也僅此而已。采用表模塊的模式往往有以下兩個結果：
（1）設計的結果主要是E-R圖或披着類圖皮的E-R圖。
（2）自然的采用數據模型但堅持認為是領域模型。
也自然而然的得到表模塊的適用范圍：
（1）業務邏輯本身就是以數據為核心的簡單處理。
（2）業務邏輯的流程十分簡單，這點和事務腳本是一致的。
3.領域模型：
領域模型同時將行為和數據作為領域邏輯的核心。因此無法像事務腳本一樣只關心過程和表面需求，也無法像表模塊一樣只關心數據。問題終於清晰了：
（1）事務腳本模式不（或逃避）深入分析需求。
（2）表模塊強調了數據，得不到充分的領域模型。
（3）領域模型模式采用通用語言解決需求問題，采用過程和數據結合解決領域邏輯的組織。
實在是不能說的再復雜了，因為本質上的簡單。由於領域邏輯本身的特性，往往會產生以下兩種傾向的領域模型：
（1）形式上類似事務腳本模式的領域模型，這是由於領域邏輯本身的特性決定，即使從代碼上看起來十分相似，但是具有更穩定和更少需求變動的優勢。
（2）形式上類似表模塊模式的領域模型。其他同上。
優勢也是實在太明顯了。我實在不能拒絕。這不是技術上的問題，這是需求分析和模型設計上的問題，我實在不能把這些簡單的概念搞的更復雜了。在使用和不斷完善通用語言的需求分析過程中，通過多次深入分析和迭代我們得到了比較穩定的需求分析，在完善設計的過程中，我們通過使用和識別出實體、值對象、領域服務和領域事件等概念，划分出聚合、子域、界限上下文來簡化我們的設計。這是在以領域邏輯為核心的前提下，不斷深入、細化和迭代的自然結果。
再次強調：
（1）DDD屬於設計范疇而非實現范疇。
（2）DDD屬於領域層的設計，別扯到架構和框架上。
（3）DDD的核心是通用語言和模型驅動設計。