面向XML的领域建模设计

在领域驱动设计（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：关系数据库下三种模式的执行特征