validation - CQRS 中的验证是否必须在 UI 中和业务域中分别进行一次？

Question

我最近阅读了文章 CQRS à la Greg Young我仍然试图让我的头脑围绕 CQRS。

我不确定应该在哪里进行输入验证，以及它是否可能必须在两个不同的位置进行(因此违反了不要重复自己的规则，也可能违反了关注点分离)。

给定以下应用程序架构:

#      +--------------------+           ||
#      |    event store     |           ||
#      +--------------------+           ||
#           ^          |                ||
#           |  events  |                ||
#           |          v                  
#      +--------------------+         events         +--------------------+
#      |      domain/       | ---------------------> |   (denormalized)   |
#      |  business objects  |                        |  query repository  |
#      +--------------------+           ||           +--------------------+
#         ^   ^   ^   ^   ^             ||                      |
#         |   |   |   |   |             ||                      |
#      +--------------------+           ||                      |
#      |    command bus     |           ||                      |
#      +--------------------+           ||                      |
#                ^                                              |
#                |             +------------------+             |
#                +------------ |  user interface  | <-----------+
#                  commands    +------------------+        UI form data  

该域隐藏在命令总线后面的 UI 中。也就是说，UI 只能向域发送命令，而不能直接访问域对象。

当聚合根对事件使用react时，不能进行验证，而是更早。

命令被转换为域中的事件(由聚合根)。这是一个可能发生验证的地方:如果一个命令不能被执行，它就不会变成一个相应的事件；相反，(例如)抛出一个异常，该异常通过命令总线向上冒泡，返回到 UI，在那里它被捕获。

问题:

如果命令将无法执行，我想禁用 UI 中的相应按钮或菜单项。但是我怎么知道一个命令是否可以在发送之前执行呢？查询端在这里对我没有帮助，因为它不包含任何业务逻辑；我在命令端所能做的就是发送命令。

可能的解决方案:

对于任何命令 DoX，引入一个相应的虚拟命令 CanDoX，它实际上不会做任何事情，而是让域反馈命令 X 是否可以正确执行。

在 UI 中复制一些验证逻辑(真正属于域的)。

显然，第二种解决方案并不有利(由于缺少 separation of concerns )。但第一个真的更好吗？

Answer 1

我想我的问题刚刚被另一篇文章解决了，Clarified CQRS通过乌迪达汉。 “命令和验证”部分的开头如下:

Commands and Validation

In thinking through what could make a command fail, one topic that comes up is validation. Validation is different from business rules in that it states a context-independent fact about a command. Either a command is valid, or it isn't. Business rules on the other hand are context dependent.

[…] Even though a command may be valid, there still may be reasons to reject it.

As such, validation can be performed on the client, checking that all fields required for that command are there, number and date ranges are OK, that kind of thing. The server would still validate all commands that arrive, not trusting clients to do the validation.

我认为这意味着——鉴于我有一个基于任务的 UI，正如通常建议的 CQRS 工作良好(命令作为域动词)——如果命令不能，我只会灰色(禁用)按钮或菜单项由于命令所需的某些数据仍然缺失或无效而被发送； IE。 UI 对命令本身的有效性使用react，而不是对命令对域对象的 future 影响使用react。

因此，不需要 CanDoX 命令，也不需要将域验证逻辑泄漏到 UI 中。但是，UI 将具有一些用于命令验证的逻辑。