API 基础设施类是否应该成为 DDD 领域的一部分？答案

【问题标题】：Should API infrastructure classes be part of the domain in DDD?API 基础设施类是否应该成为 DDD 领域的一部分？
【发布时间】：2015-12-07 04:20:11
【问题描述】：

我在开发一个公开 REST API 的后端应用程序，并且我（尝试）在我的项目中使用领域驱动设计。

REST API 在一组固定的域类上运行。对于域中的每个聚合根，都有一个单独的 REST 端点。然而，尽管付出了所有努力，但在某些情况下，会出现新的类，而不是源自域类（基础设施类），例如：

一个持有批量操作状态的类[{"id": 1, "status": "success"},{"id": 2, "status": "failure", "message": "detailed message"}]
由用户[{"column": "id", "order": 1}, {"column":"created", "order": 2 }] 选择的列的类

现在有两个选择：

【问题讨论】：

【解决方案1】：

您不应该尝试直接针对您的域模型构建 REST API。对于这样一个会弄乱您的域模型的接口，您需要承担很多责任。例如。事务控制、安全性、输入验证是您可能需要但不属于域模型的东西。

这就是应用服务的用途。

围绕包含应用程序服务的域模型构建一个薄层（通常称为服务层）。应用服务是领域模型的直接客户。它们通常围绕用例而不是聚合来组织。现在您的 REST API 是应用服务的直接客户端，而不是域模型。

您提到的两个类也可以很好地融入服务层。

编辑：

请注意，当使用六边形架构（非常适合 DDD）时，服务层与持久层不同。服务层使用持久层来加载和保存聚合到数据库。

【讨论】：

应用层基础设施是否不可知？那么REST框架是应用层的第一个客户端吗？
感谢@theDmi 的回答。我完全同意你描述的方法，但我有一个问题。假设我们有一个返回对象列表的 GET 方法，每个对象都有一个状态列。现在我们需要创建一个新的 GET 方法，它将返回一个唯一状态列表以及具有此状态的元素的数量。为此，我们创建了一个具有两个属性的新 DTO 类：String status 和 Long count。这个类应该定义在哪一层？申请，对吧？基于 DDD 的存储库是否应该返回应用层类的实例？
@AdamSiemion 这取决于图层设计。如果应用层对持久性有依赖（这很常见），那么它就不能进入应用层，因为持久层看不到它。所以在这种情况下，它会进入持久层。存储库应始终返回对应用程序有意义的对象，例如您的状态类的域对象或实例。