DDD中的数据访问？

在阅读了Evan和Nilsson的书之后,我仍然不确定如何在域驱动的项目中管理数据访问.如果CRUD方法是存储库的一部分,即OrderRepository.GetOrdersByCustomer(客户),或者它们应该是实体的一部分:Customer.GetOrders().后一种方法似乎更多OO,但它将在多个对象中为单个实体类型分发数据访问,即Customer.GetOrders(),Invoice.GetOrders(),ShipmentBatch.GetOrders()等.那么插入和更新呢？

CRUD-ish方法应该是Repository ... ish的一部分.但我想你应该问为什么你有一堆CRUD方法.他们是怎么真的吗？它们是什么真的呢？如果您确实调出了应用程序使用的数据访问模式,我认为这会使存储库变得更有用,并且当您的域中发生某些类型的更改时,您将不必执行鸟枪手术.

CustomerRepo.GetThoseWhoHaventPaidTheirBill()

// or

GetCustomer(new HaventPaidBillSpecification())

// is better than

foreach (var customer in GetCustomer()) {
    /* logic leaking all over the floor */
}

"保存"类型方法也应该是存储库的一部分.

如果你有聚合根,这可以防止你有一个Repository爆炸,或者逻辑遍布:你没有4 x实体数据访问模式,只是你在聚合根上实际使用的模式.

那是我的$ .02.

DDD通常更喜欢使用Customer.Save提示的活动记录模式上的存储库模式.

Active Record模型的一个缺点是它几乎假设一个持久性模型,除非一些特别干扰的代码(在大多数语言中).

存储库接口在域层中定义,但不知道您的数据是否存储在数据库中.使用存储库模式,我可以创建一个InMemoryRepository,以便我可以单独测试域逻辑,并在应用程序中使用依赖注入,以使服务层实例化一个SqlRepository.

对于许多人来说,拥有一个特殊的存储库只是为了测试听起来很傻,但是如果你使用存储库模型,你可能会发现你并不真正需要一个特定应用程序的数据库.有时一个简单的FileRepository会做到这一点.在您知道自己需要之前向自己婚礼到数据库是有潜在限制的.即使需要数据库,对InMemoryRepository运行测试也要快得多.

如果你没有太多的域逻辑,你可能不需要DDD.ActiveRecord非常适合很多问题,特别是如果你主要拥有数据而且只是一点点逻辑.