在领域驱动设计（DDD：Domain Driven Design）中，实现业务逻辑层主要有三种模式：Transaction Script、Domain Module和Table 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对象的加入可以减少分布式调用中的往复次数，对应用性能的提升有利。实际工程中，由于业务逻辑实体往往需要被多个客户程序调用，需要有效的并发机制配合，后续研究中将着重对并发能力进行调整。