user-interface - 命令/应用层映射的用例 : Implementation

Question

我读过的一些关于 DDD 的文本表明应用层中的应用服务或命令 (CQRS) 密切反射(reflect)了特定的用例。

对于简单的用例，这种映射是有意义的，但在需要多个用户交互的更复杂的实例中，我试图了解如何映射 API 的粗粒度级别，而不将应用程序逻辑推送到 UI 中。

例子:
- 想象一个应用服务:

ImportProductData(date_source)

从系统/用户界面的角度来看，在导入产品数据时，我们想检查是否有任何产品已经存在，如果存在，在继续之前提示用户是否要继续。

我通常的做法:
扩展 API 以包括:

DoesIncludeExistingProducts(data_source)

如果返回true，提示用户是否继续，然后调用。

ImportProductData(date_source, overwrite=True)

我的问题是这是否正在将大部分应用程序逻辑转移到 UI 层？ (即 UI 现在控制是否可以覆盖产品，以及在导入产品数据之前是否应检查现有产品等)

如果是，我无法想象应用层和领域层将如何处理这个问题？除了:

调用:

ImportProductData(date_source)

如果失败，检查失败的原因，如果由于产品已经存在，提示用户并再次调用:

ImportProductData(date_source, overwrite=True)

这感觉就像是做与上面相同的事情的不同方式。

这可能看起来有点迂腐，但我正在努力使表示层 (MVC) 尽可能地轻而薄。

关于任何更优雅的解决方案的想法？

Answer 1

首先在这里查看 Jimmy Bogards 的启发性帖子 https://jimmybogard.com/domain-command-patterns-validation/ .他不会回答你的问题，而是以一种可以让你更容易下定决心的方式攻击它。

在那篇文章中，他简要地谈到了我认为需要更多关注的一点。如果“用户经常尝试做一些我的域验证不允许的事情”，他建议不要使用异常作为通信机制。使用这个标准，我更喜欢将预期有时会失败的用例分解为验证调用，然后是执行调用。

在您的情况下，使用 IsProductSetValidForImport 之类的验证查询(不是命令)似乎很合适。在上面 Jimmy 的文章中，他努力确定返回的错误集应该有多丰富，但查询的返回集应该是丰富的，所以我们没有问题。你可以返回一个真实的、完整的 View 模型来显示给用户，而不是试图将足够的数据塞进错误字符串来绘制屏幕。我假设如果 10 个产品中有 3 个无法导入，您可能希望允许用户强制更新某些产品而不是其他产品。这给了你这个机会。

如果这个验证查询没有返回冲突，给用户一个“你确定”的消息，然后调用 API 来执行导入命令。如果在调用验证查询和发出更新命令之间发生了一些重要的状态更改，那么抛出异常并处理影响是合适的。