ami*_*ayh 10 domain-driven-design system-design cqrs event-sourcing
我是CQRS/ES世界的新手,我有一个问题.我正在开发一个使用事件采购和CQRS的发票Web应用程序.
我的问题是 - 根据我的理解,进入系统的新命令(比方说ChangeLineItemPrice)应该通过域模型,以便可以将其验证为合法命令(例如,检查此行项目是否实际存在,价格不违反任何商业规则等).如果一切顺利(命令未被拒绝) - 则会创建并存储相应的事件(例如LineItemPriceChanged)
我没有得到的是在尝试应用命令之前如何将此聚合保留在内存中.如果我在系统中有一百万张发票,每次我想申请一个命令时,我应该播放整个历史记录吗？我是否总是在没有任何验证的情况下保存事件,并在构建视图模型/投影时进行验证？
如果我误解了过程的任何部分,我将非常感谢您的反馈.
谢谢你的帮助!
Cod*_*ler 20
你并不孤单,这是一个常见的误解.让我先回答验证部分:
在这种系统中有两种类型的验证.第一种是您查找有效电子邮件地址,仅限数字或必填字段的类型.此类型在命令发出之前完成.包含这些问题的命令不应该作为命令引发(对于你可以在域方检查的带和括号,但这不是域关注,你最好只是防止这种情况).
接下来类型的验证是当它是一个领域的关注.这可能是你提到的那种你检查价格在一组指定参数范围内的东西.这是商业人士理解,做和能够表达的领域概念.
下一阶段是域应用状态更改并引发相关事件.然后将这些内容保留并成功发布,以便为应用程序的其余部分发布.
所有这一切都可以通过内存中的聚合来完成.这些操作与处理命令的域服务协调.它加载聚合,应用它的所有过去事件(或加载快照)然后发出命令.在命令成功时,它会请求所有新的未提交事件并尝试保留它们.成功后,它会发布新事件.
如您所见,它仅加载特定聚合的事件.即使有很多事件,这个过程也很快.如果性能存在问题,则可以采用诸如将聚合保留在内存或快照中的策略,您可以应用这些策略.
关于验证事件的最后一点.因为它们只能由您的聚合生成,所以它们是值得信赖的.
如果您想了解更多细节请参阅我的CQRS和ES的概述这里.并查看我的帖子,了解如何在此处构建聚合根.
祝你好运 - 我希望他们有所帮助!