CQRS - 有效的命令采购用例？
CQRS - Valid Command Sourcing Use Case?
我正在使用一个 CQRS 系统来持久化命令（带有有效负载和成功标志）。
我在客户端应用程序上有一个功能请求，要求 view/rerun 过去输入的数据。 由于我们正在存储命令有效载荷，我想知道查询命令存储的有效载荷是否合理，然后 return 将该有效载荷发送给客户端，以便它可以 "auto-fill"形成 就好像他们要重新发出命令一样。
我认为这意味着当用户发出命令时，我必须将 commandId 存储在某些读取端 table/view。它类似于这样：
- 用户输入表单数据
- 用户发出 AttachToCollectionCommand 将命令保存在预处理器中
- 在handler中，输入数据是运行针对某个service，然后保存output和collectionId在某个tableA.
- 仍然在处理程序中，commandId（连同 collecitonId）被保存到其他一些 table B.
- post-处理器更新命令成功标志。
现在，稍后，当用户打开该集合时，我们可以为该集合的每个条目加载输入数据（来自 B）和输出数据（来自 A）。
我的问题是，查询此命令存储的有效负载以填充用于集合中某个成员的输入数据是否有意义？这是此命令存储的有效用例吗？我可以看到一个问题，如果输入最终发生变化，它将使向后兼容变得更加困难。
谢谢
在通用的 CQRS 和事件溯源中，不需要命令存储，只需要事件存储，但也没有任何限制。因此，用例的有效性取决于您的业务。你觉得有效就有效
你看到的“如果输入最终发生变化，将使得向后兼容变得更加困难”的问题不只是一句话。重放命令存储类似于自动化 UI 测试。一开始它看起来像是灵丹妙药，但当你深入细节时，它变得脆弱且难以维护。在您的业务逻辑中可能会发生很多事情，这些事情会使传入的命令无效，以至于维护回放系统本身将成为一项工作。
我担心走这条路是用户的期望。命令回放系统的 V1 会做很多工作，但不会非常复杂。用户会喜欢它并想要添加功能。然后 V2 出现了，你不仅要维护命令重放引擎，还要添加一个命令转换引擎。这是很多脆弱的 if-then 语句来移动和操作数据。然后 V3 来了，你想放弃整个事情，因为它太浪费时间了，但用户不会让你。
如果您能让用户同意您只会重播来自同一发行版本的命令，那么事情会变得更容易，但这限制了他们的好处，因为他们无法重播去年圣诞节大热潮中的命令。
命令重放是 QA 在测试过程中反复重放场景的好主意，但这真的只是一个集成测试吗？ QAs 价值来自于探索性测试，而不是重复测试相同的东西。
对不起，我的咆哮。如果用户在考虑到开发和维护时间要求的情况下需要此功能，则使用存储的命令是一种有效的方法。我只是确保请求者知道每个版本需要多少维护才能保持正常工作。否则你就是在浪费所有的努力。
我正在使用一个 CQRS 系统来持久化命令（带有有效负载和成功标志）。
我在客户端应用程序上有一个功能请求，要求 view/rerun 过去输入的数据。 由于我们正在存储命令有效载荷，我想知道查询命令存储的有效载荷是否合理，然后 return 将该有效载荷发送给客户端，以便它可以 "auto-fill"形成 就好像他们要重新发出命令一样。
我认为这意味着当用户发出命令时，我必须将 commandId 存储在某些读取端 table/view。它类似于这样：
- 用户输入表单数据
- 用户发出 AttachToCollectionCommand 将命令保存在预处理器中
- 在handler中，输入数据是运行针对某个service，然后保存output和collectionId在某个tableA.
- 仍然在处理程序中，commandId（连同 collecitonId）被保存到其他一些 table B.
- post-处理器更新命令成功标志。
现在，稍后，当用户打开该集合时，我们可以为该集合的每个条目加载输入数据（来自 B）和输出数据（来自 A）。
我的问题是，查询此命令存储的有效负载以填充用于集合中某个成员的输入数据是否有意义？这是此命令存储的有效用例吗？我可以看到一个问题，如果输入最终发生变化，它将使向后兼容变得更加困难。
谢谢
在通用的 CQRS 和事件溯源中，不需要命令存储，只需要事件存储，但也没有任何限制。因此，用例的有效性取决于您的业务。你觉得有效就有效
你看到的“如果输入最终发生变化，将使得向后兼容变得更加困难”的问题不只是一句话。重放命令存储类似于自动化 UI 测试。一开始它看起来像是灵丹妙药，但当你深入细节时，它变得脆弱且难以维护。在您的业务逻辑中可能会发生很多事情，这些事情会使传入的命令无效，以至于维护回放系统本身将成为一项工作。
我担心走这条路是用户的期望。命令回放系统的 V1 会做很多工作，但不会非常复杂。用户会喜欢它并想要添加功能。然后 V2 出现了，你不仅要维护命令重放引擎，还要添加一个命令转换引擎。这是很多脆弱的 if-then 语句来移动和操作数据。然后 V3 来了，你想放弃整个事情，因为它太浪费时间了，但用户不会让你。
如果您能让用户同意您只会重播来自同一发行版本的命令，那么事情会变得更容易，但这限制了他们的好处，因为他们无法重播去年圣诞节大热潮中的命令。
命令重放是 QA 在测试过程中反复重放场景的好主意，但这真的只是一个集成测试吗？ QAs 价值来自于探索性测试，而不是重复测试相同的东西。
对不起，我的咆哮。如果用户在考虑到开发和维护时间要求的情况下需要此功能，则使用存储的命令是一种有效的方法。我只是确保请求者知道每个版本需要多少维护才能保持正常工作。否则你就是在浪费所有的努力。