CQRS 中的验证和错误修复

发布于 2024-09-26 05:07:50 字数 456 浏览 0 评论 0原文

我了解了 CQRS 的一般概念,但在超越示例代码和幻灯片来处理现实世界问题时,我有一些问题。

  1. 验证

    当您需要验证涉及检查数据库中的值的命令时,您会做什么? 注册一项服务时,我必须输入一个唯一的电子邮件地址。我听到的一个论点是,用户不太可能输入重复的电子邮件地址,因此只需在处理命令时处理它并向他们发送一封电子邮件说“抱歉”,或者建议他们重置密码。因此,此过程避免了为了验证而使用读取模型。但是如何处理命令处理程序中的重复情况呢?那么你怎么知道它是重复的?检查读取模型?您不妨首先使用它以获得更好的可用性。

  2. 功能更改/修复错误

    当您需要更改命令的工作方式或修复错误时会发生什么?在仅附加哲学中,我该如何处理所有旧命令和命令处理程序?我无法将它们重命名为 _legacy 并将它们隐藏起来,否则我的事件反序列化将无法工作。有哪些优雅的解决方案可以解决这个问题?

谢谢

I get the general concept of CQRS, but I've got a few questions when it comes to moving beyond the example code and slide decks that are out there to dealing with real world problems.

  1. Validation

    When you need to do validation of a command that involves checking values from the database, what do you do?
    Take registration for a service, I must enter a unique email address. One argument i've heard is that its very unlikely that the user will enter a duplicate email address, so just handle it when processing the command and send them an email saying "sorry", or perhaps suggesting they reset their password. This process therefore avoids having a readmodel for the sake of the validation. But how do you deal with the duplicate case in the command handler? how do you know THEN that its a duplicate? check a readmodel? you might as well have used that in the first place for better usability.

  2. Changes to functionality/fixing bugs

    What happens when you need to change the way a command works, or fix a bug? In the append-only philosophy, what do I do with all the old commands and command handlers? I can't rename them to _legacy and hide them away otherwise my event deserialization won't work. What elegant solutions are there to dealing with this?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ㄟ。诗瑗 2024-10-03 05:07:50
  1. 请参阅 http://codebetter。 com/blogs/gregyoung/archive/2010/08/12/eventual-consistency-and-set-validation.aspx 以及有关此主题的各种讨论的 cqrs 邮件列表。
  2. 事件版本控制(不需要与事件版本控制相同的命令版本控制)也在 cqrs 邮件列表上讨论。重播事件以获取聚合的当前状态,而不是命令。这样你的功能就可以发展。没有办法改变过去,但有办法改变现在/未来。在奇怪的情况下,您必须以不同的方式开始跟踪状态,提供明确的命令。对于事件的新属性,只需提供默认值,就像为新数据库列提供默认值一样。如果这些新值基于已存在的状态,则建模一个显式命令来预先计算它们。优点是您可以异步执行此操作,而数据库升级也会迫使您更改代码。最好在 cqrs 邮件列表上询问如何工作。
    一个警告!不要太轻视事件溯源。您只需使用 CQRS 就可以了。我看到人们在大多数情况下使用 CQRS 就可以切换到 CQRS+ES。

因此,请访问 groups.google.com/group/dddcqrs 并获取帮助。另一个有用的资源是 cqrsinfo.com

  1. See http://codebetter.com/blogs/gregyoung/archive/2010/08/12/eventual-consistency-and-set-validation.aspx and the cqrs mailing list for the various discussions on this very topic.
  2. Event versioning (there's no need for command versioning in the same sense as event versioning) is also discussed on the cqrs mailing list. Events are replayed to get to the current state of an aggregate, not commands. This way your functionality can evolve. There's no way to change the past, but there are ways to change the present/future. In the odd case you have to start tracking state in a different way, provide an explicit command. For new properties on events, just provide defaults as you would for a new database column. If those new values are based on state already present, then model an explicit command to precalculate them. The advantage is that you can do this asynchronously, whereas a database upgrade forces you to change the code as well. How that would work is better asked on the cqrs mailing list.
    One warning! Don't take on event sourcing too lightly. You can get by with just CQRS. I see people switching over to CQRS+ES when most of the time CQRS will do.

So come on over to groups.google.com/group/dddcqrs and get help. Another useful resource is cqrsinfo.com

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文