我正在尝试在新项目中使用CQRS和EventSorcing。我遵循几年前Greg Young提出的建议(Mark Nijhof实现-http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/)。我还有一些关于此解决方案可扩展性的问题。
Mark Nijhof在this文章中提到了一些要点。但是现在的问题是Denormalizer部分，该部分负责更新报告数据库。我想使这部分异步，因此在将事件发布到总线后，我想立即返回控制。我们建议将Denormalizer实现为独立的Web服务(WCF)，它将处理传入的事件并使用批处理命令以定时方式对报表数据库进行更新。看来这可能是一个瓶颈，所以我们现在还想添加一些可伸缩性-集群解决方案。但是在集群的情况下，我们无法控制报告数据库更新的顺序(或者我们应该实现一些奇怪的方法，我猜是会检查报告数据库中对象版本的错误逻辑)。另一个问题是解决方案的可持续性:在失败的情况下，我们将放宽非规范化程序中的更新，只要我们不将其持久化就可以了。因此，现在我正在寻找该问题的解决方案(反规范化可扩展性)，欢迎任何想法!
最佳答案
首先，您肯定要在一个单独的进程中托管反规范化器。从那里，您可以将域发布到您的消息传递基础结构中，该域中发生的事件。一种有助于加速非规范化的简单策略是按消息/事件类型将事件分解。换句话说，您可以为每种消息类型创建一个单独的队列，然后使非规范化器(使用消息总线)订阅相应的事件。这样做的好处是，您不会让消息堆积在另一个消息的后面，而是一切都开始并行运行。您可能会发生争用的唯一地方是在监听多种类型的表上。即使这样，您现在也已经在许多端点之间分配了负载。
只要您使用某种消息传递基础结构，在尝试进行非规范化时就不会丢失事件消息。相反，经过一定次数的重试后，该消息将被视为“中毒”，并被移至错误队列。只需监视错误队列中的问题即可。一旦消息进入错误队列，您就可以检查日志以查看其原因，解决问题，然后再移回去。
另一个考虑因素是马克·尼霍夫(Mark Nijhof)的例子有些古老。 DDD/CQRS Google Group中提供了许多CQRS框架以及大量建议。
关于.net - CQRS + EventSourcing可扩展性，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5647179/