Spring和HIbernate对DDM设计的支持

A：数据访问对象

    DAO和资源库在领域驱动设计中都很重要。DAO是关系型数据库和应用之间的契约。它封装了Web应用中的数据库CRUD操作细节。另一方面，资源库是一个独立的抽象，它与DAO进行交互，并提供到领域模型的“业务接口”。
   资源库使用领域的通用语言，处理所有必要的DAO，并使用领域理解的语言提供对领域模型的数据访问服务。
   DAO方法是细粒度的，更接近数据库，而资源库方法的粒度粗一些，而且更接近领域。此外，一个资源库类中能注入多个DAO。资源库和DAO能防止解耦的领域模型去处理数据访问和持久化细节。
    领域对象应该只依赖于资源库接口。这就是为什么是注入资源库、而不是DAO会产生一个更规则的领域模型的原因。DAO类不能由客户端（服务和其它的消费者类）直接调用。客户端应该始终调用领域对象，领域对象再调用DAO将数据持久化到数据存储中。
    处理领域对象之间的依赖关系（比如实体及其资源库之间的依赖关系）是开发人员经常遇到的典型问题。解决这个问题通常的设计方案是让服务类或外观类直接调用资源库，在调用资源库的时候返回实体对象给客户端。该设计最终导致前面提到的贫血领域模型，其中外观类会开始堆积更多的业务逻辑，而领域对象则成为单纯的数据载体。好的设计是利用DI和AOP技术将资源库和服务注入到领域对象中去。
   示例应用在实现贷款处理领域模型时遵循了这些设计原则。

B.持久化

    持久化是一个基础设施方面，领域层应该与其解耦。JPA通过对类隐藏持久化实现的细节，提供了这一抽象。它由注解推动，所以不需要XML映射文件。但同时，表名和列名嵌在代码中，在某些情况下可能并不是一个灵活的解决办法。
     使用提供数据网格解决方案的网格计算产品，比如Oracle的Coherence、WebSphere的Object Grid、GigaSpaces，开发人员在建模和设计业务领域时，完全不需要考虑RDBMS。数据库层用内存对象/数据网格的形式从领域层抽象出来。

C.缓存

    在我们讨论领域层的状态（数据）时，我们不得不谈到缓存问题。经常访问的领域数据（比如抵押贷款处理应用中的产品和利率）很值得缓存起来。缓存能提高性能，减少数据库服务器的负载。服务层很适合缓存领域状态。TopLink和Hibernate这些ORM框架也提供数据缓存。
    贷款处理示例应用使用JBossCache框架来缓存产品和利率详情，以减少数据库调用、提高应用性能。

D.事务
    对保持数据完整性、整体提交或回滚UOW（工作单元模式）来说，事务管理是很重要的。应该在应用架构层的哪里处理事务一直存在争议。交叉实体的事务（在同一UOW中跨越多个领域对象）也影响在哪里处理事务这一设计决策。
    一些开发人员倾向于在DAO类中管理事务，这是一个欠佳的设计。该设计导致过细粒度的事务控制，对那些事务跨越多个领域对象的用例来说，这种事务控制没有 灵活性。服务类应该处理事务；即使事务跨越多个领域对象，服务类也能处理事务，因为在大多数用例中，是服务类在处理控制流。
    示例应用中的FundingServiceImpl类处理资金申请的事务，通过调用资源库执行多个数据库操作，并在单一事务中提交或回滚所有的数据库变化。