在領域驅動設計（DDD：Domain Driven Design）中，實現業務邏輯層主要有三種模式：Transaction Script、Domain Module和Table Module。隨著業務邏輯復雜程度的增加，采用各模式實現的工作量變化趨勢有所不同；根據應用特點，三種模式也各有優勢：
1、Transaction Script：業務邏輯直接用SQL腳本與數據庫交互，實現簡單，但是限於SQL面向過程化的特點，完成復雜業務邏輯時工作量較大。
2、Domain Module：將業務數據封裝為業務對象，適於業務邏輯復雜的應用，但需要O/R映射的支持。
3、Table Module：將業務數據組織成數據表方式，雖然對象化特征不如Domain Module明顯，但適於展現層使用。
圖1：實現所需工作量與業務邏輯復雜度的關系
應用建設初期選擇的實現模式隨著業務需求和歷史數據量的變化可能需要進行調整，此時要增加一個適應性機制，保證在盡量不影響客戶程序的前提下，選擇合適的實現模式。隨著XML數據使用日趨廣泛，須借助XPath、XQuery和XSL為層次型數據增加專門的擴展機制，使得基於XML數據源的業務邏輯也可以采用上述三種模式實現。
概要設計
整體邏輯結構
總體適配機制如下：
圖2：總體實現結構
為業務服務增加抽象接口IDomainService，客戶程序通過DomainServiceFactory獲得該抽象接口，這樣客戶程序不依賴於具體的業務服務實體類，僅依賴於抽象的服務接口，當下層實現模式調整時，不影響客戶程序；為了讓框架可以同時適應關系數據庫和XML數據，增加了抽象接口IDataSource，代表不同的數據源對象；IDataMapper負責根據不同的數據源，完成關系數據或XML數據與業務對象的映射；為了減少DomainServiceFactory與具體業務服務對象產生依賴，增加配置管理對象ConfigManager，由它獲取指定的業務服務的實體類名稱，並通過反射機制動態生成目標實例。
性能改進
由於業務實體經常會對應到具有Master-Detail關系的多個表，而且有些復雜業務實體本身會包含一組或幾組其它業務實體，出於性能考慮，為了避免IDataMapper在映射過程中頻繁調用數據源逐個生成子業務實體，需要在IDataMapper與數據源之間增加一個DTO(Data Transfer Object)對象IDataTransferObject，通過將調用打包的辦法，減少頻繁的遠程調用。
圖3：借助DTO，Domain Module對象間接訪問數據源
詳細設計
面向關系數據庫的業務服務設計
為了將業務實體納入適配機制的管理，依據依賴倒置原則，先對各模式實現的業務實體進行抽象。
圖4：關系數據庫方式下的適配機制
為每種模式實現的業務對象抽象獨立接口，並編寫對應的關系數據庫實現類；Domain Module需要調度數據映射和DTO進行關系數據與業務實體的映射；增加抽象基類DomainModuleBase，通過調用IDataMapper和IDataTransferObject完成數據提取和映射工作。
表1：關系數據庫下三種模式的執行特征
面向XML數據的擴展設計
由於XML的層次特征，3個模式的實現技術與關系數據庫不同：
表2：XML數據下三種模式的執行特征
圖5：XML數據方式下的適配機制
配置機制設計
通過增加服務接口工廠類的方式隔離客戶程序與具體業務服務實體類間的依賴，工廠類通過配置管理ConfigManager獲得每個目標服務接口對應的實體類名稱，借助反射動態包裝目標服務接口。靜態結構和執行過程如下：
圖6：配置管理機制
圖7：客戶程序獲得業務服務接口的時序關系
實驗環境准備及實驗結果分析
測試業務對象
為了比較三種模式實現特點的不同，測試中設計了2個具有Master-Detail特征的業務實體：Customer和Order，兩者之間也存在1：N的關系，對應的關系數據庫和XML數據實現如下：
圖8：業務實體
圖9：關系數據庫方式下業務實體實現
圖10：XML數據方式下業務實體的實現
目標服務是一個根據客戶名稱，返回其所有訂單明細項小計之和的接口。
測試內容准備
針對關系數據庫和XML數據方式的不同，業務邏輯如表3。其中，XML數據的Transaction Script模式為了計算簡單，增加一個采用XSTL生成 “客戶名稱—訂單項明細小計”的中間過程：
圖11：XML
Transaction Script方式下生成中間結果的XSLT。
表3：兩種數據模型下三個實現模式的計算方法
測試數據
表4：測試數據
測試結果及分析
通過修改ConfigManager中實現業務服務的實體類名稱，結合數據庫調用監控獲得如下數據：
表5：測試結果
測試結果分析如下：
1）借助適配機制，在目標實現模式甚至數據模型修改時，客戶程序保持穩定，修改內容控制在配置文件部分，不影響客戶程序的業務邏輯；
2）使用不同模式設計完成的業務對象，借助適配機制和XML數據擴展機制，在關系數據庫和XML數據方式下，可完成同樣的服務功能；
3）通過DTO組件的調用打包作用，可以將包括2份訂單、4項訂單明細的信息一次性提取，將多次調用打包為1次調用，減少了網絡往復。
總結
依據依賴導致原理設計的適配機制可以從一定程度上減少客戶程序與業務邏輯的耦合程度，在部署、運行環境變化時，可通過調整配置選擇合適的業務邏輯實現模式，並且不需要客戶程序聯動修改；DTO對象的加入可以減少分布式調用中的往復次數，對應用性能的提升有利。實際工程中，由於業務邏輯實體往往需要被多個客戶程序調用，需要有效的並發機制配合，後續研究中將著重對並發能力進行調整。