企業應用架構模式中明確提出了三種領域邏輯組織模式：事務指令碼、領域模型和表模組。不少人看的雲裡霧裡的，不少人說的似懂非懂的，主要原因是沒有從專案的級別的分析和設計經驗，只有單個專案模組的開發經驗的人很難理解到位。
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的核心是通用語言和模型驅動設計。