我已经看了很多关于EventStores的文章,但所有的文章都伴随着关于CQRS的讨论。
我们希望使用EventStores来集成有界上下文,但希望坚持使用传统的对象关系映射来读/写聚合,以避免命令/查询和分离的读取模型,在我们的例子中,这会增加太多的复杂性。
考虑到同时讨论这两个概念是如此流行,以至于让人相信他们注定要生活在一起--与为聚合/ CQRS /读取模型实现EventStores相比,没有CQRS的EventStore 'lite‘有陷阱吗?
发布于 2013-03-27 23:31:34
我们希望使用EventStores来集成有界上下文
可以将事件存储用作消息队列,其附加好处是它是持久的,并且新订阅者可以请求所有过去的事件。
,但希望坚持使用传统的对象关系映射来读/写聚合,以避免命令/查询和分离的读取模型,这在我们的例子中会增加太多的复杂性。
顺便说一句,您仍然可以通过简单地对查询使用单独的read-model而不是行为模型来获得CQRS的一些好处。
总的来说,您可以在不使用event sourcing的情况下使用EventStore,但是您应该确保它支持您的集成场景的所有需求。除了事件存储之外,您可能还需要其他组件。更广泛地说,事件存储可用于存储任何时间序列数据。
https://stackoverflow.com/questions/15655037
复制相似问题