我正在使用一个CQRS系统，该系统可以保留命令（带有有效负载和成功标志）。
我在客户端应用程序上有一个功能请求，以查看/重新运行过去输入的输入数据。 由于我们正在存储命令有效负载，所以我想知道是否有必要查询命令存储中的有效负载，然后将该有效负载返回给客户端，以便它可以“自动填充”表单如果他们要重新发出命令。
我认为这意味着当用户发出命令时，我将不得不将commandId存储在某些读取侧表/视图上。它类似于：
现在，以后，当用户打开该集合时，我们可以为该集合的每个条目加载输入数据（来自B）和输出数据（来自A）。
我的问题是，甚至查询此命令存储区的有效载荷来填充用于集合某个成员的输入数据是否有意义？这是此命令存储区的有效用例吗？我可以看到一个问题，如果输入最终发生变化，则向后兼容将更加困难。
谢谢
答案 0 :(得分：1)
在通用CQRS和事件源中，不需要命令存储，只需要事件存储，但是也没有任何限制。因此，用例的有效性取决于您的业务。如果您认为有效，则该有效。
您所看到的“如果输入最终发生变化，将使向后兼容更加困难”的问题值得一句话。重放命令存储类似于自动UI测试。起初看起来像万能药，但是当您进入细节时，它变得脆弱且难以维护。您的业务逻辑中可能发生太多事情，这会使传入的命令无效，因此维护重播系统本身将成为一项工作。
我担心走这条路是用户的期望。命令重播系统的V1可能需要很多工作，但并不会非常复杂。用户会喜欢它并希望添加功能。然后V2出现了，您不仅需要维护命令重播引擎，还必须维护命令转换引擎。这是很多脆弱的if-then语句来移动数据并对其进行操作。然后V3出现了，您想抛弃所有内容，因为这会浪费时间，但用户不会允许您。
如果您可以使用户同意只重播同一发行版中的命令，则事情会变得容易一些，但这会限制他们的利益，因为他们无法重播去年圣诞节大潮中的命令。
命令重播对于质量检查人员来说是在测试过程中重复重播场景的好主意，但这真的不是一个集成测试吗？ QA值来自探索性测试，而不是重复测试同一件事。
对不起，我对此感到抱歉。如果在给定的开发和维护时间要求下，用户希望使用此功能，则使用存储的命令是一种有效的方法。我只是确保请求者知道每个版本需要多少维护才能保持正常运行。否则，您将浪费所有精力。