Answers:
当您决定更改系统架构时，您将从事件源中获得最大收益。至少在我看来，采用CQRS风格的架构与DDD相结合将带来事件采购的真正好处。
建立一个在大型系统中表现良好的事件存储确实不是一件容易的事。重放所有数据的确可能是昂贵的，它很大程度上取决于需要重放的数据量。但是有些技术可以帮助您解决这一问题，其中之一就是快照的概念。仅从某个特定点开始进行重播。事件存储带入系统的优势是无价的。使系统中发生的所有事情都可重播，每一刻的所有数据都是一件好事。考虑分析，关于错误的复制，关于统计。
有很多很棒的活动商店，最后一个是昨天才在活动商店发布的，看起来真的很不错。
可以保留传统数据库供系统的查询部分使用所需的数据构建DTO。可以根据您的应用程序和客户端的查询需求来组织和优化该数据库。
我写了一篇详细的文章，讲述了CQRS架构与事件源相结合的好处以及它的真正外观。您可以查看CQRS，域事件和DDD审核。
使用事件源，主要问题是“您的记录簿是什么”。
如果您的记录簿是您的事件流，那么您将没有任何问题。如果您的记录簿是您的“实体模型”，那么问题将开始在各地发生。部分原因是您可以说“如果我丢失了实体模型，可以从事件流中重建它”。如果您对此问题持肯定态度，那么您的事件日志就是您的记录。
同样重要的是要记住，大多数使用事件源的人都使用读取模型。该模型用于查询数据。但是，与3nf实体模型相比，这看起来更像1nf模型。它们仅重播事件以获取聚合的状态，以确定是否应允许写入。
我仍然可以拥有一个包含所有实体的数据库，对吗？还是应该在每次启动应用程序时重播事件以获取内存中每个实体的最新版本？
答案取决于您的应用程序要求。我已经看到它完成了两种方式。
一个针对小型会计公司的非常成功的软件包，每次启动时都会读取其CQRS日志。原始数据量相对较小，因此即使在速度较慢的计算机上，启动时间也不到一分钟。在这种做法流行之前，他们已经进行了CQRS十多年了。当他们意识到可以一次又一次地升级客户端数据而不会遇到大型系统所遇到的麻烦时，他们就知道自己的状况很好。
在具有大量数据的系统和/或依赖RDBMS功能实现查询方的系统中，您有一个数据库用于存储事件源数据的“当前视图”（您甚至可以拥有多个此类视图）。这种方法的优势在于，它使您可以使用熟悉的技术来构建查询方。