使用CQRS和事件来源时的唯一性验证 [英] Uniqueness validation when using CQRS and Event sourcing

查看:99
本文介绍了使用CQRS和事件来源时的唯一性验证的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试通过Event Sourcing实现自己的CQRS基础架构,以更好地学习它。作为一个示例项目,我正在实现一个博客引擎,我知道它可能不是一个完美的选择,但我只想在实际的东西上工作。

I'm trying to implement my own CQRS infrastructure with Event Sourcing to learn it better. As a sample project I'm implementing a blog engine, I know it might not be a perfect fit but I just want to work on something real.

我的问题是ve现在是验证。每个帖子都有一个 shortUrl ,并且 shortUrl 应该是唯一的,但是我应该将该验证放在域中的什么位置?我知道我将在通过从我的读取存储区读取命令来发送命令之前进行验证,以在创建create post命令或update post命令时检查它是否有效。

The problem I've come to now is validation. Every post have a shortUrl, and the shortUrl should be unique, but where should I put this validation in the domain? I know that I will have that validation before I even send the command by reading from my read store to check if it is valid when creating a create post command or update post command.

我可以想到两个解决方案。

I can think of two "solutions".


  1. 拥有 Blog 个汇总跟踪所有与博客相关的设置,以及对所有帖子的引用。但是我眼中的问题是,在这种情况下,以及每次需要验证 shortUrl 的唯一性时,我都必须处理聚合之间的通信。读取事件存储中的所有事件以创建所有帖子,这似乎很复杂。

  2. 第二种选择是触发事件并创建读取模型的事件处理程序当它注意到将有两个指向不同帖子的短网址时,触发一个重复的短网址事件。读取模型在检测到错误时触发事件是否有效?

  1. Have a Blog aggregate that keep tracks of all blog related settings and also references to all the posts. But the problem with this in my eyes is that I have to handle communication between aggregates in that scenario as well as every time I need to validate the uniqueness of a shortUrl I need to read all the events from the event store to create all the posts and that seems to complicated.
  2. The second alternative I have is when the event gets fired and my event handler that creates the read model fires a duplicate short url event when it notice that it will have two short urls that points to different posts. Is it valid to have the read model to fire events when it detects errors?

还有其他选择吗?请注意,我知道我的域可能不是最适合cqrs和DDD的域,但是我这样做是为了在一个小的域中学习。

Are there any more alternatives. Note that I know that my domain might not be the best fit for cqrs and DDD, but I'm doing this to learn in a small domain.

推荐答案

我将去一个仅负责生成唯一的ShortURL的应用程序服务。您可以使用事务性数据库来实现此行为。通常,此服务将由BlogPost聚合的命令处理部分使用。如果存在重复的ShortURL,则可以触发DuplicateUrlErrorEvent。
您可以使用相同的数据源通过创建瘦查询模型在UI中预先捕获(但绝不能100%捕获),因此您可以在提交帖子之前查询简短的URL是否唯一(如所述通过@RyanR的答案)。

I would go for an application service that is just responsible for generating unique ShortURL's. You can use a transactional DB to implement this behaviour. Typically this service would be used by the command handling part of the BlogPost aggregate. If there is a duplicate ShortURL, you can fire a DuplicateUrlErrorEvent. You can pre-catch this in the UI (but never 100%) by creating a thin query-model using the same data-source, so you can query whether a shortified URL is unique before submitting the post (as described by @RyanR's answer).

这篇关于使用CQRS和事件来源时的唯一性验证的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆