使用CQRS在DDD中进行命令验证 [英] Command Validation in DDD with CQRS
问题描述
我正在学习DDD并利用CQRS模式。我不了解如何在不读取数据存储的情况下在命令处理程序中验证业务规则。
例如，克里斯想给Ashley礼物。
命令可能是GiveGiftCommand。
我会在什么时候验证Chris确实拥有他想要给的礼物？以及如何在不读取数据库的情况下做到这一点呢？ / p>
命令可以被拒绝，如果该命令无效，我们可以对命令说否。
通常，您会在UI上进行一次验证，并且该验证可能在命令处理程序中重复（有些人也倾向于将其放在域中）。然后，命令处理程序可以运行简单的验证，该验证可以发生在实体外部，例如格式正确的数据，是否存在期望的值等。
业务逻辑，不应在命令处理程序中。它应该在您的域中。
所以我认为基本问题是...
我应该查询命令处理程序的读取端？
我会拒绝。不要在命令处理程序或域逻辑中使用读取模型。但是，您始终可以从客户端查询您的读取模型，以获取命令所需的数据并验证命令。您将在客户端上查询读取端，以检查Chris是否真正拥有他想要给予的礼物。当然，涉及读取模型的验证最终可能是一致的，这当然是另一个原因，该命令可能会从命令处理程序内部的聚合中被拒绝。
有些人不同意说，如果您要求您的命令包含处理程序验证您的命令所需的数据，那么您永远不能在不影响客户端的情况下更改处理程序/域中的验证逻辑。这给客户暴露了太多的领域知识，并且与客户只想表达意图的事实背道而驰。因此，他们倾向于向您的命令处理程序提供 GiftService 接口（这是普遍存在的语言的一部分），然后根据需要实现该接口-其中可能包括查询读取端
我认为客户端应始终假定其发出的命令将成功。不需要调用读取方来验证命令。很难获得两个矛盾的命令（用户使用相同的电子邮件地址创建帐户）。然后，您应该具有发出纠正措施的手段，例如Saga / Process Manager。因此，如果可以先验证命令而不是首先分派命令，那么采取纠正措施就不会那么麻烦。
I am learning DDD and making use of the CQRS pattern. I don't understand how to validate business rules in a command handler without reading from the data store.
For example, Chris wants to give Ashley a gift.
The command might be GiveGiftCommand.
At what point would I verify Chris actually owns the gift he wants to give? And how would I do that without reading from the database?
There are different views and opinions about validation in command handlers.
Command can be rejected, we can say No to the command if it is not valid.
Typically you would have a validation that occurs on the UI and that might be duplicated inside the command handler (some people tend to put it in the domain too). Command handler then can run simple validation that can occur outside of the entity like is data in correct format, are there expected values, etc.
Business logic, on the other hand, should not be in a command handler. It should be in your domain.
So I think that the underlying question is...
Should I query the read side from Command Handlers?
I would say no. Do not use the read model in the command handlers or domain logic. But you can always query your read model from the client to fetch the data you need in for your command and to validate the command. You would query the read side on the client to check would if Chris actually owns the gift he wants to give. Of course, the validation involving a read model is likely to be eventually consistent, which is of course another reason a command could be rejected from the aggregate, inside the command handler.
Some people disagree saying that if you require your commands to contain the data the handler needs to validate your command, than you can never change the validation logic within your handler/domain without affecting the client as well. This exposes too much of the domain knowledge to the client and go against the fact that the client only wants to express an intent. So they would tend to provide an GiftService interface (which are part of the ubiquitous language) to your command handler and then implement the interface as needed - which might include querying the read side.
I think that the client should always assume that the commands it issues will succeed. Calling the read side to validate the command shouldn't be needed. Getting two contradictory commands is very unlikely (users creating accounts with the same email address). Then you should have a mean to issue a corrective action, something like for example a Saga/Process Manager. So instead making a corrective action would be less problematic that if the command could have been validated and not dispatched in the first place.
这篇关于使用CQRS在DDD中进行命令验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
