architecture - 在应用程序服务中进行验证以检查 DTO 的 id 是否有效或 dto 的属性之一是否为空白是否是不好的做法？

Question

我的应用程序服务中有验证逻辑，用于确定请求的操作是否成功，如果没有，原因。我质疑这是否是代码异味，因为它在应用程序服务中而不是域服务中，它围绕检查域模型是否存在、dto 中的属性是否可以为空等展开。代码如下:
我在域模型中进行验证，例如在创建 时新事件() .构造函数对其传递的值进行基本验证，例如名称不能为空或为空。但是在为此编写测试时，我开始质疑验证逻辑是否应该位于可以单独测试以进行验证的域服务中。然后可以测试此方法以确保正确调用所有依赖项。这让我怀疑这是域泄漏到应用程序层还是被认为是应用程序级逻辑。但与此同时，获取 DTO 并验证值不是域的责任，对吗？

Answer 1

我通常会问这个问题是吗？用户 可能做错了，或者是 开发商 针对 API 实现可能做错了吗？后者我的意思是，针对 API 实现的开发人员首先不应该允许用户发送一些不完整的请求。
如果您的 API 严格定义必须设置属性(即强制)我已经在 上验证了这一点。 API 或应用层 .无需将其传递给域层。因此，如果针对 API 实现的开发人员(例如在前端代码中)忘记确保发送的数据符合规范，则在接收和处理来自 REST 调用的数据时，应该已经引发错误，来自队列的消息或使用任何其他通信协议(protocol)。我当然是在谈论 的不变量。与业务逻辑无关 在这个级别。
这当然并不意味着在某些情况下也会在域层中检查类似的东西。域模型类不应允许使用无效数据构建，因此在接收到无效属性时引发错误也将是域层的责任。
检查明显的错误 之前 将其移交给域层也遵守 快速失败原则，并且可能避免不必要的操作，例如在调用域模型操作时从数据库加载聚合失败，该操作将失败，因为无论如何都没有通过请求正确传递参数。
还要考虑一下，如果一旦发生这种情况可能没有太大影响，但考虑到客户端代码中存在一些错误，如果会进行大量无效调用，您确实可以节省大量资源。

Is it bad practice to have validation in the application service that checks if a DTO's id is valid or if one of the dto's properties is blank?

所以如果你是 不检查业务不变量 但反对 无效的 API 规范 我说这甚至是很好的做法。