最近看了下《企業應用架構模式》，裏面提到了事務腳本跟領域模型兩種建模方式，作者比較推崇領域模型，認爲在複雜業務下面可擴展與可維護性更好。但是在實際工作中其實並沒有特別的體會，並且之前一直使用的都是類似事務腳本的方式，比較簡單易懂，不需要太多思維轉換與跳躍。
下面就列舉一下工作中使用兩種方式架構對比下，體驗下兩者的差異。
事務腳本
顧名思義，事務腳本即將每個用例作爲一個腳本，使用數據庫編排的方式實現，之前有一個操作餘額的項目，基本功能包括創建賬戶，支付，提現等操作，使用的就是事務腳本，個人覺得代碼質量還不錯，是工作中少有的比較有成就感的項目。
下圖是創建賬戶的操作
下圖是支付的操作
代碼包結構
整體結構
其中命令層使用的數據模型都是直接來自DB層的DO（dataobject），不過在DO中添加了一些業務語義，例如增加餘額等方法。整個結構很清晰，沒有增加一些額外的實體（與數據庫一一對應，而且與業務模型對應），理解成本低，基本直接線性閱讀就可以理解。由於這個項目偏底層一些，屬於比較穩定的基礎設施，後續需求非常少，因此擴展性與維護性沒有實際校驗。
領域模型
現在集團都在推行領域模型，基本到了全民領域模型的地步了，下面就對團隊負責的支付平臺爲例，看看使用了領域模型的應用一次調用過程。
其中至少涉及到了兩次的模型轉換，而且這些模型轉換之間往往一直都是同步變更的，這樣在修改一個模型時往往需要修改多個類，並非起到了隔離變化的作用。
使用領域模型的一個優勢是可以將業務邏輯收斂（通常被認爲是穩定的邏輯，更準確應該叫確認性的邏輯，因爲業務會變化），但是其實事務腳本的模型也可以實現類似的邏輯，不過不可否認，當業務模型的關係變得複雜的時候，如果還是將數據層DO與業務邏輯放在一起會增加複雜性。
總結
其實無論是事務腳本還是領域模型也好，只要可以降低系統的複雜度，增加系統的可讀，可擴展，可維護性就可以，當系統業務邏輯並不是很複雜，使用事務腳本成本更低，而且可讀性更好。使用一層領域模型還增加一些額外成本，尤其是各個域都想着通過SPI的方式隔離變化，這樣會導致模型越來越多，而且之間的轉換也很多。關於架構與設計的方法論很多，但是需要結合實踐來看，做到真正的可落地有實效的方法。