Cok*_*aka 4 message-queue cqrs event-sourcing
CQRS/ES架构中的有界上下文之间的通信是通过事件实现的; context A生成事件作为对命令的响应,然后通过事件总线(消息队列)将这些事件转发到上下文B.
或者......您可以将事件存储在eventstore中(属于上下文A).或者......两者(存储和转发).
我的问题是:从上下文B,我应该从上下文存储中提取事件吗？或者只是消费通过事件总线推送的事件？
我倾向于拉动方式.因为那时我们可以在上下文B中进行一些追赶.相反,在推送方法中,上下文B可能不知道在B遇到停机时传递的事件.
所以......这意味着......当我们有eventstore时,我们可以简单地忘记消息队列(似乎是多余的)？
或者我在这里遗漏了什么？
您将要查看没有Pub/Sub的Consume事件流
在DDD欧洲会议上,我意识到与我交谈的发言人(sic)尽可能避免发布/发布.
以下讨论可能具有价值.TL; DR:那里没有很多pub/sub的粉丝.
Konrad Garus 推或拉？,描述拉设计:
在后一种(和更简单的)设计中,它们只传播已保存新事件的信息及其顺序ID(以便所有预测可以估计它们背后有多少).唤醒后,执行程序可以继续其正常路径,从查询事件存储开始.
为什么？因为来自单个源的处理事件更容易,但更重要的是因为DB支持的事件存储可以简单地保证排序,并且不会丢失或重复消息.鉴于我们按主键顺序读取单个表,并且大多数时候数据仍在RAM缓存中,因此查询数据库的速度非常快.瓶颈在于投影线程更新其读取模型数据库.
在大的情况下,它归结为:当人们考虑事件采购时,他们真的在考虑历史,而不是孤立的事件.如果你真正想要的是一个没有间隙的有序事件序列,那么查询该序列的权限要比尝试从一堆不相交的事件消息重建一样好得多.
但是 - 一旦你决定这样做,那么突然之间历史以及其中出现的所有事件都会成为上下文api的一部分.当团队A决定不同的事件存储实现更合适时会发生什么？他们可以推出自己服务的新版本,还是需要大量停机,因为每个消费者都必须更新？
同样,如果我们决定将上下文A重构为上下文C和上下文D,会发生什么？同样,我们是否必须在上下文B中使用以获取我们需要的数据？
也许真正的问题是上下文B与上下文A中的历史耦合,那些历史应该是私有的吗？上下文B应该访问上下文A的数据,还是应该将该工作委托给上下文A的功能？
关于SOA的 Udi Dahan 论文可能会在这个方向上开始你的思考.
| 归档时间： |
|
| 查看次数： |
565 次 |
| 最近记录： |