目前領域邏輯的組織模式分為三種，“事務腳本”，“領域模型” 以及 “表模塊”。

事務腳本類似於面向過程編程，事務腳本有以下優點：

  • 它是一種大多數軟件工程師都能理解的簡單過程模型。
  • 它能和一個行數據入口或表數據入口簡單的數據源很好的協作。
  • 非常容易設定事務的邊界。

一個組數據源操作便是一個獨立的事務腳本。 當然事務腳本也存在很大的缺陷，當領域邏輯開始變得複雜時，這些缺點就開始暴露出來。 當幾個事務要執行類似的邏輯時，通常幾個腳本中會含有某些相同的代碼。 通過將這些代碼提取出來，來形成公共的子例程，來消除這種情況。 但是，很多時候消除副本會變得棘手，而檢測副本則更困難，倒是消除副本後的程序反而比以前還要雜亂無章，難以維護。

複雜的領域邏輯，必然要引入對象，解決前面描述問題的面向對象方法就是領域模型。 一個內容管理系統會有用戶，文章等類，進行鑑權，以及寫入等邏輯均置於領域模型中。 因此，發佈對象調用一次寫入方法。 可能還會有其他例程來完成一些讀取功能，但它其實都是調用領域模型中已有打方法實現的。

領域模型的控制不再是由一個過程來控制用戶某一個動作的邏輯，而是由每個對象都承擔一部分相關邏輯。

領域模型的開銷來自於數據源的複雜度和使用上的複雜性，剛剛接觸領域模型的人會需要時間來適應這種思維方式。一旦習慣了，你就會很爽！ 另一方面你需要將數據源映射到領域模型上，數據源越是複雜，領域模型的效果就越是顯著。

上為事務腳本

上為領域模型

第三中為領域邏輯的組織模式為表模塊，它處於事務腳本和領域模型的一箇中間地帶。 和領域模型最大的區別就是在表模塊中一個表只對應一個實例，而領域模型一行數據便能對應一個實例。

表模塊的優點在於可以很容易的和軟件架構中已經存在的部分銜接，很多GUI應用都是假定將其與SQL查詢結果的記錄集結果協同工作的。表模塊就工作在記錄集之上。你可以很容易的使用。

抉擇

別問，問就，直接使用領域模型。

接下來我稍微介紹一下目前各個框架/庫在領域邏輯的組織模式上的選擇（只列出我用）：

  • PHP

    • PHP 原生 <事務腳本>
    • ThinkPHP <領域模型>
    • Laravel <領域模型>
    • YII <領域模型>

  • Java

    • java.sql.* <事務腳本>
    • MyBatis <表模塊>
    • JPA <領域模型>

  • Go

    • gorm <表模塊 | 領域模型> （這個比較神奇）

現在用表模塊的人普遍比較多，我曾遇到好幾個J2EE工程師都並不喜歡JPA的思維模式。