我们是否要查询活动商店?什么时候以及如何?

发布于 2025-02-12 15:20:52 字数 920 浏览 0 评论 0原文

我是事件采购的新手,但是如我所了解的那样,当我们有命令用例时,我们会在内存中实例化,从事件存储中应用事件,以使其处于正确状态,以进行正确的更改然后将这些更改存储回活动商店。我们还拥有一个读取模型商店,最终将通过这些更改来更新。

就我而言,我有一个createUserusecase(这是命令用例),我想首先检查用户是否已经存在以及是否已获取用户名。例如,类似的内容:

        const userAlreadyExists = await this.userRepo.exists(email);

        if (userAlreadyExists) {
           return new EmailAlreadyExistsError(email);
        }

        const alreadyCreatedUserByUserName = await this.userRepo
        .getUserByUserName(username);

        if (alreadyCreatedUserByUserName) {
           return new UsernameTakenError(username);
        }

        const user = new User(username, password, email);
        await this.userRepo.save(user);

因此,对于保存方法,我将使用事件存储并将未承诺的事件附加到其中。 和getUserByUsername方法的存在呢?一方面,我想进行特定的查询,以便我可以使用读取模型存储来获取所需的数据,但另一方面,这与CQR矛盾。那么,在这些情况下,我们该怎么办?我们是否以某种方式执行查询到活动商店?我们以什么方式做到这一点?

先感谢您!

I am new to event sourcing, but as fas as I have understood when we have a command use case, we instantiate an aggregate in memory, apply events to it from the event store so as to be in the correct state, make the proper changes and then store those changes back to the event store. We also have a read model store that will eventually be updated by these changes.

In my case I have a CreateUserUseCase (which is a command use case) and I want to first check if the user already exists and if the username is already taken. For example something like this:

        const userAlreadyExists = await this.userRepo.exists(email);

        if (userAlreadyExists) {
           return new EmailAlreadyExistsError(email);
        }

        const alreadyCreatedUserByUserName = await this.userRepo
        .getUserByUserName(username);

        if (alreadyCreatedUserByUserName) {
           return new UsernameTakenError(username);
        }

        const user = new User(username, password, email);
        await this.userRepo.save(user);

So, for the save method I would use the event store and append the uncommitted events to it. What about the exists and getUserByUserName methods though? On the one hand I want to make a specific query so I could use my read model store to get the data that I need, but on the other hand this makes a contradiction with CQRS. So what do we do in these cases? Do we, in some way, perform queries to the event store? And in what way do we do this?

Thank you in advance!

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

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

发布评论

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

评论(1

花开雨落又逢春i 2025-02-19 15:20:52

不应将CQR解释为“不要查询写模型”(因为从写入模型确定命令处理目的的状态的过程需要查询,所以此限制是站不住脚的)。取而代之的是,将其解释为“与您用于更新意图的查询具有不同的查询数据模型是完全可以接受的”。该公式意味着,如果写模型非常适合给定查询,则可以针对写模型执行查询。

事件采购可以说是(尤其是与某些用法样式结合使用)的数据模型中的终极,该数据模型优化了为写入与阅读,因此事件采购的模型几乎使几乎所有的查询都在相当小的集合之外,因此某种形式的某种形式的某种形式需要CQR。

活动商店包含的查询设施通常受到限制,但是一个查询任何合适的事件商店都会有的任何查询(因为重播活动需要)是一个复合查询,相当于“给我该实体的最新快照,要么要么是(如果存在快照)该快照之后的第一个 n 事件,或(如果没有快照)该实体的第一个 n 事件”。该查询的结果是“该实体已发表的事件”的问题(诸如保留之类的模型等)?

CQRS shouldn't be interpreted as "don't query the write model" (because the process of determining state from the write model for the purpose of command processing entails a query, this restriction is untenable). Instead, interpret it as "it's perfectly acceptable to have a different data model for a query than the one you use for handling intentions to update". This formulation implies that if the write model is a good fit for a given query, it's OK to execute the query against the write model.

Event sourcing in turn is arguably (especially in conjunction with certain usage styles) the ultimate in data models that optimize for write vs. read and accordingly the event-sourced model makes nearly all queries outside of a fairly small set so inefficient that some form of CQRS is needed.

What query facilities an event store includes are typically limited, but the one query anything that's a suitable event store will have (because it's needed for replaying the events) is a compound query that amounts to "give me the latest snapshot for that entity and either (if the snapshot exists) the first n events after that snapshot or (if no snapshot) the first n events for that entity". The result of that query is dispositive (modulo things like retention etc.) to the question of "has this entity published events"?

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