存在实现CQRS +事件源架构的各种示例应用和框架,并且大多数描述使用事件处理器来从存储在事件存储中的域事件创建非规范化视图.
托管此体系结构的一个示例是作为web api,它接受写入端的命令并支持查询非规范化视图.此Web api可能会扩展到负载平衡服务器场中的许多计算机.
我的问题是读取模型事件处理程序托管在哪里？
可能的情况:
在单独的主机上托管在单一的Windows服务中. 如果是这样,那不会造成单点故障吗？这可能使部署复杂化,但它确实保证了单个执行线程.缺点是读取模型可能会出现延迟增加的情况.
作为web api本身的一部分托管. 如果我正在使用EventStore,例如,对于事件存储和事件订阅处理,将为每个单个事件触发多个处理程序(每个Web场进程中一个),从而在处理程序尝试读/写时引起争用到他们的读店？或者,对于给定的聚合实例,我们是否保证在事件版本顺序中一次处理一个所有事件？
我倾向于方案2,因为它简化了部署并且还支持需要也监听事件的流程管理器.虽然只有一个事件处理程序应该处理单个事件,但情况相同.
EventStore可以处理这种情况吗？其他人如何在最终一致的架构中处理事件处理？
编辑:
为了澄清,我在谈论将事件数据提取到非规范化表中的过程,而不是在CQRS中读取那些表中的"Q".
我想我正在寻找的是我们如何"应该"实现和部署可以支持冗余和扩展的读取模型/ sagas/etc的事件处理的选项,当然假设事件处理是以幂等方式处理的.
我已经阅读了两个可能的解决方案,用于处理在事件存储中保存为事件的数据,但我不明白哪个应该用于另一个.
活动巴士
事件总线/队列用于在保存事件后通常由存储库实现发布消息.感兴趣的各方(订阅者),例如阅读模型或传奇/流程管理者,以某种方式使用总线/队列来以幂等方式处理它.
如果队列是pub/sub,这意味着每个下游依赖项(读取模型,sagas等)每个只能支持一个进程来订阅队列.不止一个流程意味着每个流程处理相同的事件,然后竞争以使下游变更.幂等处理应该处理一致性/并发性问题.
如果队列是竞争消费者,我们至少可以在每个Web场节点中托管订户以实现冗余.虽然这需要每个下游依赖的队列; 一个用于sagas /流程管理器,一个用于每个读取模型等,因此存储库必须发布到每个以获得最终的一致性.
认购/饲料
订阅/馈送,其中感兴趣的各方(订户)按需读取事件流并从已知检查点获取事件以便处理成读取模型.
如果需要,这对于重新创建读取模型非常有用.但是,按照通常的发布/订阅模式,似乎每个下游依赖项只应使用一个订阅者进程.如果我们为同一事件流注册多个订户,例如每个Web场节点中有一个订户,则他们都将尝试处理和更新相同的相应读取模型.
事件存储中的"根聚合"和"聚合"之间有什么区别？
即使经过数小时的搜索,我也无法准确定义这些内容.我的理解是聚合是一个ID表,它将商店内的事件(集合)组合在一起,通常使用对象表示,这也是聚合类型的原因.
另外,我已经看到了带有版本号的聚合表,我发现它们本质上是表示事件集合的组/容器/聚合ID,这让我感到困惑.
有人评估过NCQRS和JOliver的EventStore吗？是否有明显的优势或针对不同的受众？
我见过的:
NCQRS内置了对NServiceBus的支持.不确定支持的NSB版本,但NSB的许可变更使我的项目成为一个问题.不要以为我想永远坚持使用NSB 2.1.我可能会更多地关注MassTransit或RSB.NCQRS似乎也有相当数量的"入门"帮助,这对于像我这样的新手来说很受欢迎.
EventStore似乎有一个总线机制的钩子,但没有内置的实现(可能是错误的).EventStore似乎在3.0版本中有相当多的近期活动,但除了一些简短的代码示例和我发现的播客之外,似乎没有太多的帮助,特别是对于初学者,除了筛选堆栈溢出或组.
如果存在比较,请指出我的方向.如果我的上述假设不正确,请纠正我.
我在使用JOliver的Event Store在单个事务中对多个聚合的更新有疑问.据我所知,每个聚合都应该有自己的事件流.现在,虽然许多命令处理程序只会加载一个聚合并只更新该聚合(即为这些聚合保存事件),但我可以想象会有需要更新多个聚合的命令处理程序.当然,我想以交易方式做到这一点.
但是,我不知道如何使用Event Store做到这一点.通过调用CommitChanges()事件流来完成存储事件.如果我们要更新多个聚合,则会有多个事件流,因此会有多个调用CommitChanges().制作该事务的唯一方法是将其包装在一个TransactionScope,但这没有多大意义,因为底层存储技术可能不支持事务.所以我最终得到了这个代码,这绝对不是我想要的:
Guid aggregateGuid1 = Guid.NewGuid();
Guid aggregateGuid2 = Guid.NewGuid();
Guid commitGuid = Guid.NewGuid();
var stream = store.OpenStream(aggregateGuid1, 0, int.MaxValue);
stream.Add(new EventMessage() { Body = new MonitorDisabled { MonitorGuid = aggregateGuid1, User = "A" } });
stream.CommitChanges(commitGuid);
stream = store.OpenStream(aggregateGuid2, 0, int.MaxValue);
stream.Add(new EventMessage() { Body = new MonitorEnabled { MonitorGuid = aggregateGuid2, User = "B" } });
// Can't commit twice with the same commit id, what if fails …我已经阅读了Jonathan Oliver的.NET EventStore库,我必须说这个概念对我很有吸引力:只有一个简单的无依赖库,它是非侵入式的,只关注事件来源,留下了很多选择数据库,消息传递等技术时的自由
我的问题:Java世界中是否也有类似的东西？我知道有各种与CQRS相关的框架,比如Axon和Jdon,但这些框架不仅仅是事件采购......也许是在任何一个简单的端口上工作的人？
尽管我已经深入了解了NEventStore上的事务完整性,但我无法理解当NEventStore的许多实例连线时NEventStore如何真正扩展.
总结一下我的理解,一个事件被添加到未提出的提交,然后它发布给调度员,然后标记为已调度.
同时,无论何时连接NEventStore,它都会查找未分配的事件,然后调度它们并将事件标记为已分派.
但是,当新事件存储的连线将看到即将发送的未分配事件(来自其他商店)时,必须有一个短时间跨度.新的事件存储将再次发送事件.
想想这个架构:
Client -> Command Bus -> Command Handler -> EventStore persist -> Dispatch to Event Handlers
如果我们有很多Command Handlers来处理我们的负载,我们也会坚持许多事件.
如果我们经常处置或创建Command Handlers,那么许多EventStore将被连线并导致调度已经被分派的事件.
我知道调度员的消费者应该是幂等的,这不是我的问题.我的问题是我们是否会在高负载情况下向命令处理程序的消费者提供不必要的负载量？
在J Oliver的EventStore中,打开流时我应该如何使用streamId？
我应该为每个对象/聚合根对象创建一个新的stream/streamid吗？
那么,我的订单状态对象我认为应该是ar对象,每个对象都有一个streamid？
我正在开始一个将在Windows Azure上托管的新项目.我使用RavenDb作为后端,我想使用CQRS和事件采购.
我阅读了Jonathan的EventStore的好评,它完全适合我的架构,因为它是一个薄层,可以使用RavenDb作为商店.现在,我注意到3.0版本(最新的官方版)已经有一年了,新的3.1还没有发布(分支中有一些活动).我想去3.1版本,因为它集成了CommonDomain项目,但我没有任何问题,单独引用版本3.0和当前的CommonDomain.
我只是想知道EventStore是否正在积极开发并将继续维护,尤其是在Greg Young发布他的EventStore(geteventstore.com)之后.我有点不愿意去了,因为它与它自己的持久性和AFAIK我将无法保存我的活动我RavenDb.
总结一下:
PS.我不介意分叉joliver的EventStore并提供修复/次要功能.
也许这个问题很愚蠢,但我有点困惑.让我们假设我们想要利用这种模式:
企业应用程序中的事件存储范围究竟是什么？
事件存储是在多个进程之间共享,还是只是一个进程内概念？
当应用程序关闭时,事件会发生什么？它们是绑定到应用程序"实例"还是应用程序？
事件存储和MessageBus与发布者/订阅者之间有什么区别(我们可以存储消息历史记录的一部分？
谁对信息幂等负责？
我对CQRS和DDD比较陌生,我想知道在域模型中实现投票机制的最佳方法是什么.
在产品上,用户可以upvote/downvote.关于投票有一些域规则,你只能投票一次,无论是向下还是向上投票.
投票和产品都是聚合根.这是最好的方法吗？建议保持聚合较小.将投票添加到产品聚合根将超时使其变得臃肿.
我正在努力解决的问题是当投票是聚合根时删除投票.您需要知道需要删除哪个投票聚合.在命令处理程序中,无法使用productId和userId从存储库中检索投票.aggregateId作为单个Guid存储在数据库中.
该命令将包含这些字段
我找到的一些可能的解决方案:
什么是最好的方法？