那如何組織 domain logic 呢?作者提供三個範式， Transaction Script, Domain Model 跟 Table Module。
就是從 presentation 拿到 input 後，直接處理跟儲存資料，然後回應給 presentation。基本上的結構就是對每個動作做 procedure ，就像 script 一樣。手法上則會有一堆 function (subroutine) 出來。
優點是 1.簡單易懂 2.搭配簡單的 data souce layer 很ok，如 Row Data Gateway or Table Data Gateway 3. 可以很明確的定義資料庫 transaction 的開始跟結束
缺點是隨著 domain logic 的複雜，重複的code會越來越多。雖然可以試著用 subroutine 把重複的code拉出，但是仍會造成結構上的複雜。
複雜的邏輯就要用物件導向的 object model 來處理，把行為跟資料都放物件中。優點是有很多OO技巧可以來組織好(design pattern)，如你在 transaction script 用很多條件句的code，在這裡你可以玩 strategy pattern 等。缺點是 1.較難些(你得先OOA分析出有哪些物件) 2. data source layer 變複雜，你得處理 object 跟 relational database 的對應問題(下一章的議題)。
介於上述兩個之間，用 object 來處理一張 資料庫 table 的 domain logic。缺點是沒辦法用很多 doamin model 的種種OO技巧。優點是在 Record Set (把SQL查詢的結果組織成 record set) 的環境它很適合。
如何做選擇?
作者列了一張圖如下，基本上建議用 Domain Model 囉，尤其是如果有好的 team。如果是 Record Set 的環境，也可以考慮 Table Module。另外這三種範式是不衝突的，你也可以在不同部分採用不同的範式。
另一個常見的手法是把 domain layer 拆成兩部份，新增一個 service layer 在 domain model 或 table module 上。而 presentation 要跟 domain 互動就是跟 service layer 互動，它代表這個 應用程式的 API。優點是加入了 transaction control 跟 security 的特點。而且用 API 來看，也容易跟 use case 配合。缺點是一但你用太多，反而變回 transaction script 了。這裡你可以看到作者的另一篇 營養不良的領域模型 正是解釋這個情況。