CQRS已经让我进入了思维模式.我试着用CQRS的想法开始一个新的项目.我喜欢的主要事情是
1)查询和命令的分离.我们的域查询一直是个问题.
2)使用事件存储进行审核 – 我不会将其用于重播 – 至少不是现在.
1)查询和命令的分离.我们的域查询一直是个问题.
2)使用事件存储进行审核 – 我不会将其用于重播 – 至少不是现在.
我对查询方面很好,我对域事件还有一些问题
如果一个命令导致更新多个聚合根(Ex.Order和OrderDetail),我将把它们定义在UnitofWork(事务)下.现在,每个域都负责在其状态发生变化时发布事件.
让我们说命令改变3 orderDetail记录.每个OrderDetail将发布2个事件.最后我们有6个事件.
a)如果我对域对象进行了更改(但未提交事务)时发布了这些事件,那么如何反转已发布的事件(可能已被订阅者使用)
>我可以想到的是将事件发布在同一单位工作范围内的列表中,一旦交易提交已经被调用,存储并发布.这听起来有什么意思吗？
b)如果OrderDetail中的更改要求在Order Aggregate Root中也发生一些更改
i)我应该通过处理由OrderDetail Aggregate发布的事件来基于这些更改吗？例如让我们说两个订单明细被删除.这使订单状态从“首选”到“不喜欢”.
ii)如果事件错误并且不更新订单状态 – 如果订单仍然是首选,则在2天内发货.
添加另一个问题
c)“域事件是所有应用程序状态更改的源”还是“所有应用程序状态更改的结果”
先谢谢你,
三月
解决方法
a)你不应该发布事件,直到你的交易被提交,一个事件重新发生了一些事情,因此它们全部以传统时间命名的原因(例如OrderClearedEvent).另外在你必须“还原”一个事件的情况下,你应该采取一个纠正措施,即你不删除事件,你必须触发一个新的事件,纠正你想恢复的事件的影响
b)似乎这更像是你对实体和命令进行建模的问题.我不能想到一个为什么OrderDetail将是一个AggregateRoot的原因,但我不知道你的域…
c)命令将导致至少一个事件被发布
希望这有帮助:)正如Rinat所说,谷歌集团是提问的最佳地方,同时也来看看cqrsinfo.com和github.com/MarkNijhof/Fohjin和github.com/gregoryyoung/m-r的示例代码
