我目前正在研究是否可以在构建特定系统时应用 CQRS，并且有一些我无法轻易找到答案的问题。
在 CQRS 中，命令用于响应用户操作。用户通过 UI 选择他们想要的操作，UI 层知道哪些命令将处理它们。
但是，有时命令根据上下文无效，例如用户角色、实体业务状态（公共、存档）和用户与实体的关系（例如，工单具有报告者和人员分配）。
命令可以将此作为整体验证的一部分进行检查。显然，如果命令对特定实体状态无效，则不应进行任何更改，因此如果适用，验证和更改应包含在事务中。
这一切都很好也很有必要，但是我们需要知道命令在 UI 层中是否有效（对于上下文，我们不关心这里的完整验证）所以适当的 UI 元素（如按钮或菜单项）将被省略，如果它不适用。因此，在我看来，详细信息/更新视图的读取模型应该返回有效命令列表。此外，如果存在列出实体的读取模型，则此处也需要使用相同的规则和代码进行类似的安全修整。
作为奖励，一些实体具有依赖于时间的状态，因此它不能存储在模型中，但必须在运行时使用当前服务器时间确定。
读取模型无法存储此类信息的事实也很明显，因为没有上下文就无法知道它。
正如我所看到的，在不违反 DRY 的情况下以用户友好和干净的方式处理这个问题（以免重复业务逻辑），我们必须在此处稍微弯曲 CQRS，方法是根据上下文和业务状态检查附加额外的查询条件并添加有效列表读取模型中的命令，因此这些系统方面变得不那么分离，并且返回读取模型的过程涉及命令处理程序。
也许我在这里担心太多，并且可以通过横切关注来允许安全修剪违反 CQRS 原则？