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