在应用服务中发送域实体作为参数或发送实体 id 作为参数

Question

在使用域驱动设计时，您的服务方法接收实体作为参数还是接收实体的 id 作为参数更好，以便您可以使用存储库检索方法内的实体？

例如：

public void Apply(Job job, User user)

对

public void Apply(int jobId, int userId)

Answer 1

我使用 ViewModel 向/从应用程序服务传递“平面实体”。我还使用文档消息模式与应用程序服务进行通信。在应用程序服务中，为业务实体使用扩展方法，如下所示：

public BusinessEntityViewModel ConvertToViewModel(this BusinessEntity businessEntity)
{
      BusinessEntityViewModel bevm = new BusinessEntityViewModel{ Id = businessEntity.Id, ...}
      return bevm;
}

Answer 2

DDD 是关于将客户的词汇映射到您的设计。您的客户（希望）谈论的是申请工作的用户，而不是某个整数 ID 链接到另一个整数 ID。尽量贴近真实世界，除非它成为负担。

通过传入整个实体，您可以立即从实体的行为中受益，而无需先构造它。

所以坚持使用实体，除非您遇到经常只有一个 ID 可以使用的情况。这通常发生在您处理外部系统（例如网络服务）时。在这种情况下，您可以创建一个接受 ID 的方法重载。此重载应验证 ID、构造实体并调用接受实体的重载。

public void Apply(int jobId, int userId)
{
    // Validate the IDs.

    // Construct the entities.
    var job = ...;
    var user = ...;

    // Call the 'proper' overload.
    Apply(job, user);
}

public void Apply(Job job, User user)
{
    // Actual business logic belongs here.
}

再次重申：尽量避免此类重载，除非您正在处理只返回 ID 的外部系统。

从编码的角度来看，实体也比整数好。整数可以是任何整数值，因此您必须在使用它的任何地方验证它。您的工厂负责构建有效实体，并且您的（域）逻辑应使您的实体处于有效状态。所以使用实体是完全安全的，不需要太多验证。

Answer 3

这取决于您的应用程序服务所在的位置：

如果您的服务在 同一个 AppDomain 内执行（即您从同一个可执行文件中调用它），那么传递对象是理想的。 Service 可以轻松访问对象图中的其他对象。

如果您的服务在不同的 AppDomain 中执行（例如，在 WebService 或其他远程位置之后），您应该使用 ID。然后，服务会在使用它之前从持久性存储中加载适当的对象。

如果您尝试通过网络发送对象，您可能会遇到problems described here。

希望对您有所帮助。

Answer 4

在我的理解中，区别仅在于 Domain 对 User 和 Job 做了什么来进行“应用”操作。如果 ID 够用，那么只留下 ID 就可以了。

Answer 5

如果您发送对象，您将在服务和实体之间创建依赖关系。使用服务的优点之一是充当外观以减少类之间的依赖图并降低设计的复杂性。最好在服务契约中使用原始类型、结构、枚举，但是在处理大量方法参数时，您可以将它们封装在一个对象中，但在这种情况下，它将是一个 DTO，而不是一个实体。