有关领域驱动设计的问题

Question

阅读 Eric Evans 的领域驱动设计后，我有几个问题。我进行了搜索，但没有找到满意的答案。如果你们中有人清楚地理解以下问题，请告诉我。

我担心的是

1. 存储库用于从数据库、Web 服务获取现有的聚合。 如果是，存储库还可以对该实体进行事务调用（即转账金额、发送帐户详细信息等）

2. 实体是否可以具有具有业务逻辑的方法，其中调用基础设施层服务来发送电子邮件..日志等（直接调用 IS 服务的实体方法）。 实体是否

3. 存储库实现和工厂类将驻留在基础设施层中。这是正确的说法吗？

4. UI层（控制器）可以直接调用Repositry方法吗？或者我们应该从应用程序层调用它们？

我心里还有很多困惑...请指导我... 我正在使用 Eric Evan 的领域驱动设计的书籍...... 使用 C# 的 .NET 域驱动设计

Answer 1

1. 关于存储库是否应该是只读的还是允许事务存在很多争论。 DDD 并不规定任何这些观点。你可以两者都做。只读存储库的支持者更喜欢所有 CUD 操作的工作单元。

2. 大多数人（包括自己）认为实体是持久无知的是很好的做法。稍微扩展一下这个原则将表明它们应该是独立的并且不受所有基础设施层服务的影响——即使是抽象形式。因此，我想说，对基础设施服务的调用属于在实体上运行的服务类。

3. 存储库实现和工厂（如果有）应该驻留在基础设施层中，这听起来是正确的。但是，它们的接口必须驻留在域层中，以便域服务可以与它们交互，而无需依赖于基础设施层。

4. DDD 并不真正决定是否可以跳过层。在本书的后面，埃文斯谈到了一些关于分层的内容，并在允许的情况下将其称为“轻松分层”，所以我猜他只是将其视为多种选择中的一种。就我个人而言，我更喜欢防止跳过层，因为如果调用已经经过正确的层，那么将来注入某些行为会更容易。

Answer 2

1. 就我个人而言，在我最新的 DDD 项目中，我使用一个包含 NHibernate 会话的工作单元。 UoW 被注入到存储库中，让它们单独负责添加、删除和查找。

2. Evans 指出 DDD 书中缺失的一个难题是“领域事件”。使用类似 Udi Dahan 的 DomainEvents 会给你一个完全解耦架构（领域对象只是引发一个事件）。就我个人而言，我使用域事件和 StructureMap 的修改版本进行连接。它非常适合我的需求。

3. 根据其他建议，我建议存储库接口成为模型的一部分，并且它们的实现成为基础设施的一部分。

4. 是的！我个人参与过三个 DDD Web 项目，其中服务和存储库被注入到演示者/控制器 (ASP.NET/ASP.NET MVC)，这在我们的上下文中非常有意义。

Answer 3

1. 存储库应该仅用于定位和保存实体，该层不应该有任何业务逻辑。例如：

   repository.TransferAmount(金额, toAccount); // 这很糟糕

2. 实体可以执行诸如发送电子邮件之类的操作，只要它们依赖于您的域中定义的抽象即可。实现应该在您的基础设施层中。

3. 是的，您将存储库实现放在基础设施层中。

4. UI层（控制器）可以直接调用Repositry方法吗？或者我们应该从应用程序层调用这些方法？

是的，我在很大程度上尝试遵循这种模式：

[UnitOfWork]
public ActionResult MyControllerAction(int id)
{
    var entity = repository.FindById(id);
    entity.DoSomeBusinessLogic();
    repository.Update(entity);
}