g18*_*18c 8 domain-driven-design neventstore
我已经看过很多关于EventStores的内容,但所有文章都与CQRS相关.
我们希望使用EventStores来集成有界上下文,但希望坚持使用传统的ORM来读/写聚合,以避免命令/查询和单独的读取模型,在我们的例子中会增加太多的复杂性.
因为它是如此流行地讨论这两个概念而导致人们认为它们意味着共同生活 - 与没有CQRS的EventStore'lite'相比,是否存在陷阱,与实现聚合/ CQRS /读取模型的EventStore相比？
运行到NoSql Distilled - 通过几天什么都不做，只是阅读它并画出你想要的内容，你会节省大量时间。如果您正在“读/写聚合”，您应该考虑诸如 RavenDB 之类的数据库。
请注意，事件存储标签适用于 JOliver 事件存储，它具有关键的架构概念
为了生成事件，您的域也以特定的方式构建，以促进这一点。与您在问题中提出问题的方式形成鲜明对比的关键事项（错误地和/或不公平地解释：我想使用事件存储只是为了存储事件 - 我可以自己完成其余的事情）
事件按聚合进行批处理 - 它是事件管理的真正单位
调度某事。
如果您不需要事件源域模型，请研究队列管理解决方案。这是一件非常合理的事情 - 只是不要假装 Event Store 是一个通用的事件发布子队列。
使用 Dispatcher Project 到 Denormalizers 来构建读取模型是很容易的 - 您可以使用各种奇特的东西，但使用熟悉的工具（如 SQL SB）和简单的数据库层（如 PetaPoco）就可以了。
你真的用 CommonDomain 和 EventStore 做过峰值吗？您读过 nuget 中的自述文件吗？您看过2 个JOliver 视频吗？