在领域驱动设计中，API基础设施类应该是领域的一部分吗？

Question

我从事一个暴露REST API的后端应用程序，我在我的项目中尝试使用领域驱动设计。

REST API基于一组固定的领域类。对于每个聚合根的领域，都有单独的REST端点。然而，尽管付出了所有的努力，还是会有新的类（基础设施类）出现，这些类并不派生自领域类，例如： - 保存批量操作状态的类 [{"id":1,"status":"success"},{"id":2,"status":"failure","message":"详细信息"}] - 用户选择的列的类 [{"column":"id","order":1},{"column":"created","order":2}]

现在有两个选项： 1. REST API是否可以公开不属于领域的类？ 2. 还是这些类应该成为领域的一部分？

- Adam Siemion

---

我认为公开特定层级的合同是完全可以的。例如，数据传输对象通常在应用程序层中定义... - plalx

Answer 1

你不应该直接针对你的领域模型构建REST API。这种接口需要很多职责，可能会破坏你的领域模型。例如，事务控制、安全性、输入验证是你可能需要的东西，但并不属于领域模型。

应用程序服务就是为此而存在的。

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

你提到的两个类也可以很好地适配到服务层中。

编辑：

请注意，当使用六边形架构（这是DDD的一个很好的适配）时，服务层不同于持久化层。服务层使用持久化层将聚合加载和保存到数据库中。

- theDmi

---

应用层基础架构是否与特定技术无关？因此，REST框架是应用层的第一个客户端？ - danfromisrael

感谢@theDmi的回答。我完全同意您所描述的方法，但我有一个问题。假设我们有一个GET方法返回对象列表，每个对象都有一个状态列。现在我们需要创建一个新的GET方法，它将返回一组唯一状态以及具有此状态的元素数量的列表。为此，我们创建了一个新的DTO类，其中包含两个属性：String status和Long count。这个类应该定义在哪一层？应用程序层，对吧？基于DDD的存储库是否应返回应用程序层类的实例？ - Adam Siemion

@AdamSiemion 这取决于层设计。如果应用程序层依赖于持久性（这很常见），则它不能进入应用程序层，因为持久性层将无法看到它。因此，在这种情况下，它进入持久性层。 存储库应始终返回对应用程序有意义的对象，例如域对象或状态类的实例。 - theDmi