CQRS 验证和独特性
在我的 CQRS 架构中，我想验证当我发送 InsertSettingCommand（设置是键/值对象）时，我想检查该键是否已存在于我的数据库中。如果我理解 CQRS &验证很好，它表示仅当验证某些格式内容（例如检查电子邮件是否遵循某些语法或客户名称不为空）时，才应在客户端执行验证。但就我而言，我需要查询数据库以查看它是否存在，但我不知道在客户端查询我的读取存储是否正确？或者我应该在我的域端调用我的阅读商店？然后抛出一个 InsertSettingDuplicated 事件？
那么，在 CQRS 环境中，针对我的情况采取的最佳方法是什么？有人谈论补偿行动？有什么可以帮助我的吗？
谢谢。
In my CQRS architecture, I'd like to validate that when I send a InsertSettingCommand (setting is a key/value object), I want to check that the key doesn't already exist in my database. If I understand CQRS & validation well, it says that the validation should be performed in client side only when it's about verifying some formatting stuffs like checking that email respects some syntax or that customer's name is not empty. But in my case, I need to query my database to see if it exists, but I don't know if it's correct to query my read store in client-side ? Or should I call my read store in my domain side ? Then throws an InsertSettingDuplicated event ?
So what's the best approch to take in my situation in a CQRS environment? Some people talk about compensating actions ? Is it something that can helps me ?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可以从客户端进行查询来读取存储以验证唯一性。 这里是 Greg Young 的一些想法使用 CQRS 基于集合的验证。
It is ok to make query from client side to read storage in order to validate uniqueness. Here is some thoughts from Greg Young about set based validation using CQRS.
理论上，您甚至不需要检查重复的密钥，您的客户端应该连接起来以自行检索此类信息，与用户输入完全分段。例如：在下拉列表中包含此类项目的列表，或任何其他选择性列表。
只有当系统无法执行某个过程时才应使用补偿操作或补偿命令，因此必须回滚一些命令或在构建到故障点时所做的任何操作。
例如，假设系统必须插入一个设置，该命令应该能够引发的唯一事件应该是“SettingInsertedEvent”之类的事件。因此，假设没有引发此事件，我们可以指示系统对此进行补偿，并回滚它在该进程中所做的任何操作。
您的命令还可以实现一个接口，通过数据管理器为您进行检查。或者您可以构建一个没有键的数据模型，并使表自动增量，这样您甚至不必完全担心这种情况。 （我确信您现在知道 dataModel 只是数据库服务器中现有表的代码表示，通过 ORM 链接到它，这是任何现代应用程序的另一个基本部分。）
In theory, you shouldnt need to even check for a duplicate key, your client side should be wired up to retrieve such info on its own, completely segmented from user input. For example: have a list of such items in a drop down, or any other selective list.
Compensative actions or compensative commands should only be used when the system failed to perform a process, and thus has to rollback a few commands or whatever it has done in the build up to the failure point.
For example, lets say the system has to insert a setting, the only event that this command should be able to raise should be something like 'SettingInsertedEvent'. So assume that this event was not raised, we can then instruct the system to compensate for this, and rollback anything it has done within that process.
Your command could also implement an interface that does the checking for you via a dataManager. Or you could just build up a dataModel without a key, and make the table auto-increment so you do not even have to worry about the scenario completely. (Im sure you know by now that a dataModel is just a code representation of an existing table in your db server, linked to it by an ORM, another fundamental part of any modern application.)