我正在尝试在我的新项目中使用CQRS和EventSorcing。我跟随Greg Young几年前的建议（Mark Nijhof实施 - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/）。我有一些与此解决方案的可扩展性有关的问题。
Mark Nijhof在this文章中提到了一些观点。但现在的问题是Denormalizer部分，它负责更新报告数据库。这部分我想要异步，所以在将事件发布到总线后我想立即返回控件。我们建议将Denormalizer实现为独立的Web服务（WCF），它将处理传入的事件并使用批量命令以定时方式更新报表数据库。它似乎可能成为一个瓶颈，所以我们还希望在这一点上增加一些可扩展性 - 一个集群解决方案。但是在集群的情况下，我们无法控制报告数据库更新的顺序（或者我们应该实现一些奇怪的，我猜错误的逻辑将检查报告数据库中的对象版本）。另一个问题是解决方案的可持续性：如果出现故障，我们将在非规范化程序中丢失更新，只要我们不将其保留在任何地方）。所以现在我看来解决这个问题（Denormalizer可扩展性）欢迎任何想法！
答案 0 :(得分：4)
首先，您肯定希望将denormalizer托管在一个单独的进程中。从那里，您可以让域发布到您的消息传递基础结构中域中发生的事件。帮助加速非规范化的一个简单策略是通过消息/事件类型将事物分开。换句话说，您可以为每种消息类型创建一个单独的队列，然后让denormalizer订阅（使用消息总线）到相应的事件。这样做的好处是你没有消息堆叠在一起 - 一切都开始并行运行。您可能有争用的唯一地方是在监听多种类型的表上。即便如此，您现在已经在许多端点之间分配了负载。
只要您使用某种消息传递基础结构，就不会在尝试非规范化时丢失事件消息。相反，在一定次数的故障重试之后，该消息将被视为“毒药”并移至错误队列。只需监视错误队列中的问题。一旦消息出现在错误队列中，您就可以检查日志以查看它的原因，解决问题，然后将其移回。
另一个考虑因素是Mark Nijhof的例子有些陈旧。 DDD/CQRS Google Group中提供了许多CQRS框架以及大量建议。