CQRS项目是否需要像NServiceBus这样的消息传递框架? [英] Does a CQRS project need a messaging framework like NServiceBus?

问题描述

最近的6个月学习曲线一直是CQRS和DDD的主要罪魁祸首.

The last 6 months learning curve have been challenging with CQRS and DDD the main culprits.

这很有趣，我们正在进行项目的1/2步，而我没有时间去研究的领域是消息传递框架.

It has been fun and we are 1/2 way through our project and the area I have not had time to delve into is a messaging framework.

当前，我不使用DTC，因此很可能出现这样的情况:如果未更新我的读取模型，则读取和写入数据库之间将出现不一致的情况.我的读写数据库也将在同一台计算机上.我怀疑我们是否会将它们放在单独的计算机上.

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. Also my read and write database will be on the same machine. I doubt we will ever put them on separate machines.

我的系统中没有大量消息，因此我更关心的是系统的一致性和可靠性.

I don't have a large volume of messages in my system so my concern is more to do with consistency and reliability of the system.

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

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? Yes there is learning curve but I suppose there would be a hell of a lot to learn if I don't use it.

此外，如果不需要，我不想放一层

Also, I don't want to put in a layer if it is not necessary

有想法吗?

推荐答案

目前，我不使用DTC，因此很有可能发生以下情况: 我的读取模型没有更新，那么我之间将存在不一致 读写数据库.

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将提供事务重试功能，但仍无法解决重试后发生故障的情况-您仍然必须注意错误日志并有适当的过程来处理错误.

Personally, I dislike the DTC and try to avoid it. Instead, it is often possible to implement a compensation mechanism, especially for something like a read model where eventual consistency is already acceptable and updates are idempotent. For example, you could implement a version on entities and have a background task which ensures versions are in-sync. Having a DTC will provide transactional retry functionality, but it still won't solve cases where failure occurs after retries - you still have to watch the error log and have procedures in place to deal with errors.

因此，我是否必须放入像NServiceBus这样的消息传递框架(甚至 尽管读写数据库都在同一台计算机上)还是我 还有其他选择吗?

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，我也不会立即回避使用它，因为我认为逻辑分区本身是有益的.另一方面，正如您所指出的，增加复杂性层的成本很高，因此，首先尝试看看最简单的方法是否可行.

It depends on a few things. What you often encounter in a CQRS system is need for pub/sub where several sub-systems publish events to which the query/caching system subscribes to. If you see a need for pub/sub beyond basic point-to-point messaging, then go with something like NServiceBus. Also, I wouldn't immediately shy away from using NServiceBus even if you don't need it for scalability purposes because I think the logical partitioning is beneficial on its own. On the other hand, as you point out, adding layers of complexity is costly, therefore first try to see if the simplest possible thing will work.

另一个要问的问题是，您是否根本需要一个单独的查询存储.如果您只有一台机器，为什么还要麻烦呢?您可以使用更简单的内容，例如

Another question to ask is whether you need a separate query store at all. If all you have is a single machine, why bother? You could use something simpler like the read-model pattern and still reap a lot of the benefits of CQRS.

这篇关于CQRS项目是否需要像NServiceBus这样的消息传递框架?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！