Onion Architecture - 需要来自基础设施信息的领域模型方法答案

【问题标题】：Onion Architecture - Domain Model methods that require information from InfrastructureOnion Architecture - 需要来自基础设施信息的领域模型方法
【发布时间】：2020-12-07 14:23:03
【问题描述】：

我刚刚开始使用 DDD 并实施洋葱架构。

我正在制作一个邀请系统，超级用户可以通过电子邮件邀请另一个用户到他的公司。但是，在创建邀请时，我想确保系统中尚未创建用户。我想通过检查该电子邮件的数据库中是否有任何记录来做到这一点。我正在使用实体框架来处理数据库上下文。

我已经为 Invitation 和 UserAccount 创建了一个存储库，其中包含基于 Id 查找项目的方法。

我需要使用 DB 上下文来查看邀请是否仍然有效，但由于该方法是在域层中声明的，所以在不破坏设计模式的情况下，我真的不知道该怎么做。域层不应该知道任何关于持久层的事情。

我想过注入 IUserAccountRepository 然后执行所需的方法以完成 Accept() 方法，但我担心这是错误的。

【问题讨论】：

DeriveAccount必须如果因为用户已经存在而无法创建帐户，则抛出异常。你真的需要另一个冗余的、不可靠的检查吗？

标签： c# entity-framework design-patterns domain-driven-design onion-architecture

【解决方案1】：

领域层不应该知道任何关于持久层的事情。

没错——领域层不应该知道持久性。

但该约束不适用于应用层。

换句话说，我们设计了我们的领域模型接口，以便它“要求”我们（可能）成功计算模型的下一个状态所需的信息，而应用程序有一个问题是要弄清楚这些信息在哪里来自。

public UserAccount Accept(Guid userId, Boolean userExistsInDatabase)

您会在某些设计中看到，我们不会传递问题的答案，而是传递提出问题的能力，让模型自己决定是否应该提出问题以及应该提出什么问题与答案有关

public UserAccount Accept(Guid userId, Roster roster)

在这种情况下，Roster 将是您的模型定义的接口，它接受模型已经拥有的一些信息并报告您的模型理解的其他一些信息。然后，您的应用程序将在调用该方法时提供此接口的实现。

Passing values across the boundaries 更“纯”一点，因为模型代码不需要知道关于名册的故障模式的任何信息——所有代码都将存在于应用层。

【讨论】：

【解决方案2】：

可以在您的域服务中使用合同。

“IUserAccountRepository”是我们在域中创建的合同，域服务不知道实现。

所以不要担心这是对的

【讨论】：