具有业务逻辑的存储库模式

Question

我只是想写一个基于DDD的演示应用程序。我的存储库使用实体框架ORM，一切都很好。MVC和Windows窗体应用程序调用存储库方法，这是可行的。但是，如果我决定用Dapper或NHibernate替换实体框架，或者我的数据来自web服务，该怎么办？我知道我需要重写存储库实现，但是用我的业务逻辑。业务逻辑现在放在Repository中。有些示例在控制器中包含业务逻辑，但我有多个客户端。我需要在Repository上面放一些层吗？DDD概念中的那一层叫什么？

Answer 1

我知道我需要重写仓库实现，但是用我的业务逻辑。业务逻辑现在放在Repository中。

这让我有点担心。如果您的业务逻辑被放在您的存储库中，那么您根本就没有实践领域驱动设计。在DDD中，您的业务逻辑位于您的域实体中。存储库的目的只是返回填充的域对象。域对象不应该知道它们是如何保存的(无论它是在数据库中、xml文件中还是动态创建的)。

域驱动设计的整个目的是将您从任何特定的基础设施中解放出来。无论您使用的是Entity Framework还是Dapper，您的域对象都应该能够工作。

Answer 2

通常，您可以创建一组表示您的域模型的类。然后，您将拥有一组用于存储库的类，这些类将接受域模型类进行读/写。这使您可以独立于另一个进行更改。

例如，域模型：

class Vehicle
{
    string id; // or you can use an appropriate key
    int noOfWheels;
    int topSpeed;
    // etc.
}

class Car : Vehicle
{
    int passengerCapacity;
    int trunkCapacity;
    // etc.
    string Serialize();
    void Deserialize(string representation);
}

和您的存储库：

class VehicleRepository
{
    void Store(Vehicle v);
    Vehicle GetVehicle(string id);
    void Delete(string id);
    // etc.
}

为了代码简洁，我避免添加接口。但是，一般来说，这种结构将允许您修改域对象，而不考虑存储库，反之亦然。因此，您可以拥有一个存储库，它将通过序列化/反序列化对象将您的对象放入NOSQL存储(或用于本地测试的文件系统)，而另一个存储库将从SQL存储中CRUD对象。

我在对象上包含了序列化/反序列化方法，这在大多数情况下都有效。然而，有时必须将其分离在单独的类中，并隐藏在存储库后面，以便使用物理存储介质进行版本控制(即，您的物理表示可能会更改，但您的域对象不应受影响，反之亦然)。

Answer 3

是否需要在存储库之上放置某些层？

是。存储库的目标是简单地从域层移除有关数据如何持久化的知识。这是为了强制分离关注点，并保持域的“纯净”。存储库通过为您的域对象提供抽象来实现这一点，从而将它们表示为内存中的集合。

但是请注意，存储库的接口应该在域中定义，因为存储库在那里为域提供服务，并且只有域可以定义其与其数据的约定。

在DDD概念中该层的名称是什么？

存储库属于基础架构层。其上的层是域层，所有业务逻辑都位于该层。