在阅读了 Eric Evans 的领域驱动设计之后，我有几个问题。我搜索过，但没有找到令人满意的答案。如果你们中的任何人对以下问题有清楚的理解，请告诉我。
我的担忧是
存储库用于从 DB、Web 服务中获取已经存在的聚合。如果是，可以存储库也有这个实体的交易调用（即转账金额，发送账户详细信息......等）
实体是否可以拥有具有业务逻辑的方法，在这些方法中它调用基础设施层服务来发送电子邮件..日志等（实体方法直接调用 IS 服务）。
存储库实现和工厂类将驻留在基础设施层中。这是正确的说法吗？
UI 层（控制器）可以直接调用 Repositry 方法吗？还是我们应该从应用层调用这些？
我的脑海中仍然有很多困惑......请指导我......我正在使用 Eric Evan 的域驱动设计的书籍...... .NET 使用 C# 的域驱动设计
关于存储库应该是只读还是允许事务存在很多争论。DDD 没有规定任何这些观点。你可以两者都做。只读存储库的支持者更喜欢所有 CUD 操作的工作单元。
大多数人（包括自己在内）认为实体是持久无知的是一种很好的做法。稍微扩展该原则将表明它们应该是自包含的并且没有所有基础设施层服务 - 即使是抽象形式。所以我会说对基础设施服务的调用属于在实体上运行的服务类。
存储库实现和工厂（如果有）应该驻留在基础设施层中，这听起来是正确的。然而，它们的接口必须驻留在域层中，以便域服务可以与它们交互，而无需依赖于基础设施层。
DDD 并没有真正规定您是否可以跳过层。在本书的后半部分，Evans 谈到了分层，并在你允许的情况下将其称为轻松分层，所以我猜他只是将其视为多种选择中的一种。就我个人而言，我更喜欢防止层跳过，因为如果调用已经通过正确的层，它可以更容易地在未来注入一些行为。
就个人而言，在我最新的 DDD 项目中，我使用了一个包含 NHibernate 会话的工作单元。UoW 被注入到存储库中，赋予它们添加、删除和查找的唯一责任人。
Evans 曾表示，DDD 书中缺少的一个难题是“领域事件”。使用像Udi Dahan 的 DomainEvents这样的东西会给你一个完全解耦的架构（领域对象只是引发一个事件）。就个人而言，我使用修改版的 Domain Events 和 StructureMap 进行接线。它非常适合我的需求。
基于其他建议，我建议将存储库接口作为模型的一部分，并将它们的实现作为基础架构的一部分。
是的！我亲自参与了三个 DDD Web 项目，其中服务和存储库被注入到演示者/控制器（ASP.NET/ASP.NET MVC）中，这在我们的上下文中很有意义。
存储库应该仅用于定位和保存实体，该层中不应有任何业务逻辑。例如：
repository.TransferAmount（金额，toAccount）；// 这是不好的
只要实体依赖于您的域中定义的抽象，实体就可以执行诸如发送电子邮件之类的操作。实现应该在您的基础设施层中。
是的，您将存储库实现放在基础架构层中。
UI 层（控制器）可以直接调用 Repositry 方法吗？还是我们应该从应用层调用这些？
是的，我尝试在大多数情况下遵循这种模式：
[UnitOfWork]
public ActionResult MyControllerAction(int id)
{
var entity = repository.FindById(id);
entity.DoSomeBusinessLogic();
repository.Update(entity);
}