我看过很多关于eventstore的文章，但是所有的文章都附带了关于CQRS的讨论。
我们希望使用EventStores来集成有界上下文，但希望坚持使用传统的ORM来读写聚合，以避免命令/查询和单独的读取模型，在我们的情况下会增加太多的复杂性。
看到它是如此流行的谈论两个概念在一起，导致相信他们是生活在一起——做一个没有CQRS的EventStore"生活"是否有陷阱，相比于实现EventStore聚合/CQRS/读模型?
运行NoSql蒸馏-你会节省很多时间，几天什么都不做，只是阅读它，并绘制出你所追求的。如果你正在"读/写聚合"，你应该考虑像RavenDB这样的数据库。
注意，事件存储标签是为JOliver事件存储准备的，它具有关键的体系结构概念
你也有一些事情是向后的，以获得产生事件，你的域以一种特定的方式构建，以促进这一点。与你在问题中假设事物的方式形成对比的关键事情(解释不好和/或不公平:我想使用事件存储只是为了存储事件-我可以自己做其余的事情)
-
事件是通过聚合进行批处理的——聚合是事件的真正管理单位
-
调度
如果你不想要事件源域模型，那就去研究队列管理解决方案。这是一件非常合法的事情——只是不要假装事件存储是一个通用的事件发布子队列。
让Dispatcher项目去反规格化器来构建读模型是很容易的——你可以使用各种各样的奇异的东西，但是使用一个熟悉的工具，比如SQL SB和一个简单的数据库层，比如PetaPoco，就可以了。
你真的做过CommonDomain和EventStore的峰值吗?你读过nuget中的自述文档了吗?你看过2 JOliver的视频吗?
- CQRS -犹他州代码营2010 -第1和2部分
- CQRS -初学者简介
- Jonathan Oliver谈Event Sourcing and EventStore @ E-VAN 2011年10月25日
我们想使用EventStores来集成有界上下文
可以使用事件存储作为消息队列，其附加的好处是它是持久的，并且新的订阅者可以请求所有过去的事件。
但是想要坚持使用传统的ORM来读写聚合，为了避免命令/查询和独立的读取模型，在我们的情况下会增加太多的复杂性。
作为题外话，您仍然可以通过简单地为查询使用单独的读取模型而不是行为模型来获得CQRS的一些好处。
总的来说，你可以在不使用事件源的情况下使用EventStore，但是你应该确保它支持你的集成场景的所有需求。除了事件存储之外，您可能还需要其他组件。更一般地说，事件存储可用于存储任何时间序列数据。