使用 ES 的 CQRS 中命令和事件的意图
我的问题与这个有关。虽然相关的问题和答案显示了我们为什么要将它们分开，但我想确保我对意图的理解是正确的。在我见过的所有示例中，命令的意图似乎是它可以被拒绝，并且它会更新内存中的对象，然后该事件将更新数据库。现在我知道我在这里过于简单化了，但是理解命令旨在更新内存和事件更新数据库是否正确？如果没有，有人可以帮我澄清一下吗？
我正在努力学习这些模式，这就是我到目前为止所掌握的方式，我想确保它是正确的。提前致谢。
My question is related to this one. While the related question and answers show why we want to separate them, I wanted to make sure my understanding of the intent was correct. In all the examples I've seen, it seems that the intention of a command is that it can be rejected and that it updates the object in memory and the event will then update the database. Now I know I'm grossly over-simplifying here but is it correct to understand it that commands are meant to update memory and events update the DB? If not, could someone please clarify for me.
I'm trying to learn these patterns and this is how I'm grasping it so far and I want to make sure it's correct. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的理解是正确的。
命令是针对域模型发出的，并要求特定的行为。域模型检查是否允许执行并做出相应的行为。命令可以被视为应该执行的特定用例。
另一方面，事件只是宣布某些事情已经发生（它们不能被拒绝，因为您无法改变过去。）
基于这些事件，您的应用程序（以及某个应用程序中的其他应用程序 ）集成场景）可以做出相应的反应——例如更新读取的模型数据库。
具体来说，当应用事件溯源模式时，事件将被存储和重放，以便在需要时重新补充您的域模型。
Your understanding is correct.
Commands are issued against the domain model and ask for a specific behaviour. The domain model checks if the execution is allowed and behaves accordingly. Commands can be viewed as a specific use case that should be executed.
Events on the other hand simply announce that something has already happened (they can't be rejected since you can't change the past.)
Based on these events your application (as well as other applications in an integration scenario) can react accordingly -- like for instance update the read model database.
Specifically when the Event Sourcing pattern is applied, then the Events are what is being stored and replayed to rehydrate your domain model when needed.
首先，我认为你并没有过度简化它。这是一个简单的概念。
命令告诉您的应用程序执行某些操作。
事件向世界宣告你做了某事。
如果您的应用程序无法执行要求执行的操作（由于业务规则或其他原因），那么它不会执行该操作。反过来也没有宣布任何事情。如果它确实做了某件事，那么它会通过一个事件来宣布它。
如果有人订阅了这些事件，并且关心它们何时发生，那么他们可以使用事件中的数据更新其应用程序。
在实践中，这通常意味着您的读取模型订阅事件并相应地自行更新。
以创建用户为例。您发出包含有关用户信息的 User_CreateCommand。然后，命令处理程序将创建一个新对象（该对象是用户），并将其保存到存储库中。创建用户会触发 User_CreatedEvent ，该事件将由您的读取模型处理，并且读取模型将被更新。任何其他监听的系统也可以自行更新。
需要一点研究的部分是，当您将用户保存到存储库时，您实际上并没有像您想象的那样保存用户对象。您实际上正在保存包含有关用户的所有数据的 User_CreatedEvent。
稍后，当您需要用户对象时，您将调用类似 _repo.GetById(1); 的内容。
然后，这将重放与该用户相关的所有事件并创建用户对象。
希望有帮助:)
First, I don't think you are over simplifying it. It is a simple concept.
Commands tell your application to do something.
Events announce to the world that you did something.
If your application can't do what it is told to do (because of business rules or some other reason) It doesn't do it. And in turn doesn't announce anything. If it does do something then it announces it via an event.
If anyone is subscribed to those events, and care when they occur, then they can update their application with the data in the event.
In practice this generally means your read model subscribes to the events and updates itself accordingly.
Take creating a User. You issue a User_CreateCommand which contains information about a user. The command handler would then create a new object, that object being a User, and save it to the repository. Creating the user fires a User_CreatedEvent which will be handled by your read model and the read model will be updated. Any other systems listening can update themselves as well.
The part that takes a little bit of study is the fact that when you save your User to the repository, you aren't actually saving a User Object like you might think. You are actually saving the User_CreatedEvent which contains all of the data about the user.
Later, when you need your user object you would call something like _repo.GetById(1);
This would then replay all of the events dealing with that user and create the user object.
Hope that helps :)