企業應用架構模式中明確提出了三種領域邏輯組織模式：事務指令碼、領域模型和表模組。不少人看的雲裡霧裡的，不少人說的似懂非懂的，主要原因是沒有從專案的級別的分析和設計經驗，只有單個專案模組的開發經驗的人很難理解到位。
事務指令碼的理解其實最簡單，但是很多人說不清，覺得比領域模型還難理解，也對應不到**。但這只是幻覺，怎麼可能最簡單的領域邏輯模式都不懂，反而對最複雜的領域模型模式懂了呢。
我們看企業應用架構模式中強調的一句話"使用過程來組織領域邏輯"，其實事務指令碼就是從過程的角度看待需求，需求方和開發方在此階段都熱衷的核心是"這個功能是怎麼個過程"，二者達成一致後用**去將這個粗糙的過程模擬出來。所以大多數人都在不自覺的應用事務指令碼模式。簡單說就是使用過程化的**在模擬使用者表面的需求。如果這個專案繼續進行下去，那麼問題來了：
（1）使用者自己都不太清楚需求，需求肯定會隨著使用者的想法變化而不斷變化。即使你作為需求方如果不仔細思考，只是簡單的陳述下表面的流程，你也會經常性的由於自己偶爾的深入考慮或更沒譜的想法而不斷的變更需求。
（2）事務指令碼模式的**是過程式的，需要什麼呼叫什麼，常見的資料來源通訊、郵件服務、應用級別的日誌安全等各種**都混合在一起，如果需求變了，調整起來很困難。
這就是很多專案的一般狀態，因為問題的根源在沒有深入分析和理解使用者的需求，所以不是用什麼框架和分層，搞一些似是而非的實體或者採用了ioc和aop等技術實現能起作用的的。還是要從根源上尋求解決之道，因此領域驅動設計強調通用語言，這樣才能同需求人員一起對具體的領域進行深入的分析，這樣的需求分析和模型設計具有更高的穩定性，才不會因為需求方的腦抽和風暴導致需求頻發大幅度變化。
一旦你了解了事務指令碼模式的核心，你就十分清楚事務指令碼的適用範圍：
（1）領域邏輯本身就是多個簡單過程。
（2）需求十分簡單，即使看起來表面化也已經足夠深入。
在此提醒大家，要學習領域驅動設計千萬別跑偏，不要忘記領域邏輯本身才是一切的分析和設計的根源。尤其是初學者千萬不要把非領域層和應用層的各種框架技術和元件之類的混入到學習中。在分析和設計的過程中，至少要堅持兩點：
（1）不要在此時關注表示層和資料來源層
（2）盡量多從專案整體的角度看待問題，不要只以開發者的角度去思考。
事務指令碼依然可以使用各種技術和框架，但無論你怎麼命名檔案和使用什麼元件，依然是以過程來組織業務邏輯。以事務指令碼模式組織領域邏輯的設計結果必然是以一系列的流程圖為核心。
表模組不再將過程作為組織領域邏輯的核心，而是將資料作為領域邏輯的核心。一些在深受事務指令碼模式的毒害的團隊可能意識到了過程的變化太不可**了，而往往又不去或不能在需求分析上下功夫，因此從技術角度抓住了業務邏輯中相對過程更穩定的資料部分。也僅此而已。採用表模組的模式往往有以下兩個結果：
（1）設計的結果主要是e-r圖或披著類圖皮的e-r圖
。（2）自然的採用資料模型但堅持認為是領域模型。
也自然而然的得到表模組的適用範圍：
（1）業務邏輯本身就是以資料為核心的簡單處理。
（2）業務邏輯的流程十分簡單，這點和事務指令碼是一致的。
領域模型同時將行為和資料作為領域邏輯的核心。因此無法像事務指令碼一樣只關心過程和表面需求，也無法像表模組一樣只關心資料。問題終於清晰了：
（1）事務指令碼模式不（或逃避）深入分析需求。
（2）表模組強調了資料，得不到充分的領域模型。
（3）領域模型模式採用通用語言解決需求問題，採用過程和資料結合解決領域邏輯的組織。
實在是不能說的再複雜了，因為本質上的簡單。由於領域邏輯本身的特性，往往會產生以下兩種傾向的領域模型：
（1）形式上類似事務指令碼模式的領域模型，這是由於領域邏輯本身的特性決定，即使從**上看起來十分相似，但是具有更穩定和更少需求變動的優勢。
（2）形式上類似表模組模式的領域模型。其他同上。
優勢也是實在太明顯了。我實在不能拒絕。這不是技術上的問題，這是需求分析和模型設計上的問題，我實在不能把這些簡單的概念搞的更複雜了。在使用和不斷完善通用語言的需求分析過程中，通過多次深入分析和迭代我們得到了比較穩定的需求分析，在完善設計的過程中，我們通過使用和識別出實體、值物件、領域服務和領域事件等概念，劃分出聚合、子域、界限上下文來簡化我們的設計。這是在以領域邏輯為核心的前提下，不斷深入、細化和迭代的自然結果。
（1）ddd屬於設計範疇而非實現範疇。
（2）ddd屬於領域層的設計，別扯到架構和框架上。
（3）ddd的核心是通用語言和模型驅動設計。
領域邏輯的組織模式
c 領域邏輯組織可以分為三種主要的模式 事務指令碼 transaction script 領域模型 domain model 和表模組 table module 事務指令碼 transaction script 使用過程來組織業務邏輯，每個過程處理來自表現層的單個請求。大多數應用都可以被看作是一系列...
領域驅動系列三
1 領域模型的重要性 領域模型是軟體專案中的核心,模型是團隊經過長時間的歸納總結形成的乙個與專案有關的概念集合,他用術語和關係表達了領域的深層含義,這種關係和語義提供了模型語言的語義,模型語言是為領域獨家定製的.十分的精確,並且他將開發過程和模型繫結到一起,並使 和模型緊密的繫結.但是還是要說一句,...
領域驅動設計系列 三 事件驅動上
今天講一下事件驅動，這個不是領域驅動設計裡的事件源 event source 這個以後再講，今天主要講一下如何用事件來解耦，主要的原因是我們有個專案有個功能我覺得用事件的方式比較好，正好寫篇部落格，就不用專門給他們講了。說到解耦，我們很熟悉分層設計，比如上層依賴於抽象，不依賴於具體的實現。比如乙個類...