事務指令碼：
事務指令碼的核心是過程，通過過程的呼叫來組織業務邏輯，每個過程處理來自表現層的單個請求。大部分業務應用都可以被看成一系列事務，從某種程度上來說，通過事務指令碼處理業務，就像執行一條條sql語句來實現資料庫資訊的處理。事務指令碼把業務邏輯組織成單個過程，在過程中直接呼叫資料庫，業務邏輯在服務（service）層處理。
由action層處理ui層的動作請求，將request中的資料組裝後傳遞給businessservice，bs層做簡單的邏輯處理後，呼叫資料訪問物件進行資料持久化，其中vo充當了資料傳輸物件的作用，一般是貧血的pojo，只具備getter和setter方法，沒有狀態和行為。
事務指令碼模式的特點是簡單容易理解，面向過程設計。對於少量邏輯的業務應用來說，事務指令碼模式簡單自然，效能良好，容易理解，而且乙個事務的處理不會影響其他事務。不過缺點也很明顯，對於複雜的業務邏輯處理力不從心，難以保持良好的設計，事務之間的冗餘**不斷增多，通過複製貼上方式進行復用。可維護性和擴充套件性變差。
領域模型：
領域模型的特點也比較明顯， 屬於物件導向設計，領域模型具備自己的屬性行為狀態，並與現實世界的業務物件相對映。各類具備明確的職責劃分，領域物件元素之間通過聚合和引用等關係配合解決實際業務應用和規則。可復用，可維護，易擴充套件，可以採用合適的設計模型進行詳細設計。缺點是相對複雜，要求設計人員有良好的抽象能力。
領域模型對應的就是領域驅動設計中劃分的領域層，這裡就不詳細討論了。
在實際的設計中，我們需要根據具體的需求選擇相應的設計模式。具備複雜業務邏輯的核心業務系統適合使用領域模型，簡單的資訊管理系統可以考慮採用事務指令碼模式。
領域模型 And 事務指令碼
事務指令碼和領域模型之間的區別還是很明顯的，顯然，我們常見的系統中沒有太多是採用領域建模來實現的 而大部分是採用事務指令碼來實現。我承認事務指令碼在解決簡單問題方面確實是簡單，特別是只是簡單的crud問題。事務指令碼的乙個最重要的特徵是 1.簡單的過程模型。也就是乙個service方法就對應著使用者...
業務邏輯層之事務指令碼與領域模型
在前面的部落格中，已了解了前端控制器，頁面控制器，應用控制器這三種表現層模式，如果說它們精心安排了外部世界與系統內部的通訊，那麼業務邏輯層的工作則是處理應用程式的業務部分。業務邏輯層應當遠離那些外部的 噪音 業務邏輯是整個應用程式的根本目的所在，系統的其它部分都是為這部分服務的。這裡介紹兩種經常使用...
富領域模型和貧血領域模型
貧血領域模型乙個明顯的特徵是 它僅僅是看上去和領域模型一樣，都是物件，都以領域空間中定 義的名詞命名，這些物件通過實際領域模型中豐富的關係和結構相互關聯。但是觀察模型所持有的 業務邏輯時會發現，貧血模型中除了大量 getter 和 setter，幾乎沒有其他業務邏輯。當然，在使用貧血領域模型時，那些...