nservicebus - CQRS 项目是否需要像 NServiceBus 这样的消息传递框架？

Question

过去 6 个月的学习曲线充满挑战，CQRS 和 DDD 是罪魁祸首。

这很有趣，我们已经完成了项目的 1/2，而我还没有时间深入研究的领域是消息传递框架。

目前我不使用 DTC，所以有一个很好的可能性，如果我的读取模型没有更新，那么我将在读取和写入数据库之间出现不一致。我的读写数据库也将在同一台机器上。我怀疑我们是否会将它们放在不同的机器上。

我的系统中没有大量消息，所以我更关心的是系统的一致性和可靠性。

那么，我是否必须放入像 NServiceBus 这样的消息传递框架(即使读写数据库都在同一台机器上)还是我有其他选择？是的，有学习曲线，但我想如果我不使用它，将会有很多东西需要学习。

另外，如果没有必要，我不想放入图层

想法？

Answer 1

Currently I don't use DTC so there is a very good likely hood that if my read model is not updated then I will have inconsistency between the read and write databases.

就个人而言，我不喜欢 DTC 并尽量避免它。相反，通常可以实现补偿机制，特别是对于读取模型之类的东西，其中最终一致性已经可以接受并且更新是幂等的。例如，您可以在实体上实现一个版本，并有一个确保版本同步的后台任务。拥有 DTC 将提供事务重试功能，但它仍然无法解决重试后发生故障的情况——您仍然必须查看错误日志并制定适当的程序来处理错误。

So, do I have to put in a messaging framework like NServiceBus (even though both read and write databases are on the same machine) or do I have other options?

这取决于一些事情。您在 CQRS 系统中经常遇到的是 pub/sub 需要几个子系统发布查询/缓存系统订阅的事件。如果您发现除了基本的点对点消息传递之外还需要发布/订阅，那么请使用 NServiceBus 之类的东西。此外，即使您不需要 NServiceBus 用于可伸缩性目的，我也不会立即回避使用它，因为我认为逻辑分区本身是有益的。另一方面，正如您所指出的，添加复杂层的成本很高，因此首先尝试看看最简单的方法是否可行。

要问的另一个问题是您是否需要一个单独的查询存储。如果您只有一台机器，何必费心呢？你可以使用像 read-model pattern 这样更简单的东西，并且仍然可以获得 CQRS 的很多好处。