Domain driven design 关于领域驱动设计的问题

在阅读了Eric Evans的领域驱动设计之后，我有几个问题。我搜索了一下，但没有找到满意的答案。请让我知道，如果你们有明确的理解以下问题

我担心的是

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

实体是否可以使用具有业务逻辑的方法来调用基础结构层服务以发送电子邮件。。日志等（实体方法调用的是服务直接）

存储库实现和工厂类将驻留在基础结构层。这是正确的说法吗

UI层（控制器）可以直接调用存储方法吗？或者我们应该从应用层调用它们

在我的脑海里还有很多困惑。。。请引导我。。。 我正在使用Eric Evan的领域驱动设计。。。。。。 .NET域驱动的C语言设计#

关于存储库应该是只读的还是允许事务，存在很多争论。DDD不指定这些视图中的任何一个。你两者都可以。只读存储库的支持者更喜欢所有CUD操作的工作单元

大多数人（包括自我）认为实体是持续无知的好实践。稍微扩展一下这一原则将表明它们应该是自包含的，并且不包含所有基础架构层服务——即使是抽象形式的服务。所以我想说，对基础设施服务的调用属于在实体上运行的服务类

存储库实现和工厂（如果有的话）应该位于基础架构层，这听起来是正确的。但是，它们的接口必须位于域层，以便域服务可以与它们交互，而不依赖于基础结构层

DDD并不能决定是否可以跳过层。在本书的后期，Evans谈到了分层，并称之为放松分层，如果你允许的话，那么我猜他只是将其视为几种选择中的一种。就我个人而言，我更喜欢防止层跳过，因为如果调用已经通过正确的层，那么在将来注入一些行为会更容易

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

Evans指出DDD书中缺少的一块拼图是«域事件»。使用类似的方法将为您提供一个完全解耦的体系结构（域对象只会引发一个事件）。就我个人而言，我使用域事件和StructureMap的修改版本进行连接。它非常适合我的需要

根据其他建议，我建议将存储库接口作为模型的一部分，并将其实现作为基础架构的一部分

对!！我个人曾参与过三个DDD web项目，其中服务和存储库被注入到演示者/控制器（ASP.NET/ASP.NET MVC）中，这在我们的环境中非常有意义

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

存储库.转账金额（金额，待记账）；//这很糟糕

实体可以做一些事情，比如发送电子邮件，只要它们依赖于域中定义的抽象。实现应该在您的基础架构层

是的，您将存储库实现放在基础架构层中

UI层（控制器）可以直接调用存储方法吗？或者我们应该从应用层调用它们

是的，我试着在大多数情况下遵循这种模式：

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

---

谢谢马丁，谢谢你的建议。。。。。。我认为我必须开始实施设计，而不是考虑大量的DDD，我假设一旦我开始构建应用程序，我的域设计将得到大量迭代。我同意域模型中的存储库接口和持久层中的实现的想法，但是工厂呢？从我的观点来看，陈述3有问题。工厂的职责是创建实体，因此，如果工厂位于持久层，那么实体也必须位于持久层（否则依赖倒置原则将被打破——工厂只知道实体的抽象是不够的，它需要知道具体的实现）。但是实体实现如何驻留在持久层中呢？实体不是DTO，它包含很多域逻辑！也许这些详细的解释将有助于：