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

Question

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

我的担忧是

存储库用于从 DB、Web 服务中获取已经存在的聚合。
如果是，存储库是否也可以对此实体进行交易调用(即转账金额、发送账户详细信息...等)

实体是否可以拥有具有业务逻辑的方法，在这些方法中它调用基础设施层服务来发送电子邮件..日志等(实体方法直接调用 IS 服务)。

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

UI 层( Controller )可以直接调用 Repositry 方法吗？还是我们应该从应用层调用这些？

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

Answer 1

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

大多数人(包括自己在内)认为实体是持久无知的是一种很好的做法。稍微扩展该原则将表明它们应该是自包含的并且没有所有基础设施层服务 - 即使是抽象形式。所以我会说对基础设施服务的调用属于在实体上运行的服务类。

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

DDD 并没有真正规定您是否可以跳过层。在本书的后半部分，Evans 谈到了分层，并在你允许的情况下将其称为轻松分层，所以我猜他只是将其视为多种选择中的一种。就我个人而言，我更喜欢防止层跳过，因为如果调用已经通过正确的层，它可以更容易地在 future 注入(inject)一些行为。