Question

我只是打算编写基于DDD的演示应用程序。我的存储库使用Entity Framework ORM，一切都很棒。 MVC和Windows窗体应用程序调用存储库方法，并且有效。但是，如果我决定用Dapper或NHibernate替换实体框架，或者我的数据来自Web服务怎么办？我知道我需要重写repostiory实现，但是我的bussines逻辑是什么。业务逻辑现在放在Repository中。一些示例在控制器中有业务逻辑，但我有多个客户端。我是否需要在存储库上方放置一些图层？ DDD概念中该层的名称是什么。

Answer 1

我知道我需要重写repostiory实现，但是我的bussines逻辑是什么。业务逻辑现在放在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

我是否需要在存储库上方放置一些层？

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

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

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

存储库属于基础结构层。该层之上的层是域层，所有业务逻辑都存在于该层。

存储库模式与业务逻辑

3 个答案: