在领域驱动设计（DDD：Domain Driven Design）中，实现业务逻辑层主要有三种模式 [1]：Transaction Script、Domain Module 和 Table Module。随着业务逻辑复杂程度的增加，采用各模式实现的工作量变化趋势有所不同；根据应用特点，三种模式也各有优势：
- Transaction Script：业务逻辑直接用 SQL 脚本与数据库交互，实现简单，但是限于 SQL 面向过程化的特点，完成复杂业务逻辑时工作量较大。
- Domain Module：将业务数据封装为业务对象，适于业务逻辑复杂的应用，但需要 O/R 映射的支持。
- 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 对象的加入可以减少分布式调用中的往复次数，对应用性能的提升有利。实际工程中，由于业务逻辑实体往往需要被多个客户程序调用，需要有效的并发机制配合，后续研究中将着重对并发能力进行调整。
参考文献：
[1] Fowler, Martin 著，Patterns of Enterprise Application Architecture
[2] Biping Joshi 著，Pro .Net 2.0 XML
源代码下载： DomainMechanism
评论