过去6个月的学习曲线一直具有挑战性，CQRS和DDD是罪魁祸首。
这很有趣，我们已经完成了项目的一半，我没有时间深入研究的领域是消息传递框架。
目前我不使用DTC，所以如果我的读取模型没有更新，那么我的读取和写入数据库之间就会出现不一致。我的读写数据库也将在同一台机器上。我怀疑我们是否会把它们放在不同的机器上。
我的系统中没有大量的消息，所以我更关心的是系统的一致性和可靠性。
那么，我是否必须放入像NServiceBus这样的消息传递框架(即使读写数据库都在同一台机器上)，或者我是否有其他选择？是的，有学习曲线，但我想如果我不使用它，会有很多东西需要学习
此外，如果不需要，我不想放一层
想法？
目前我不使用DTC，所以如果我的read模型没有更新，那么我将在读取和写入数据库。
就我个人而言，我不喜欢DTC，并尽量避免它。相反，通常可以实现补偿机制，尤其是对于读取模型这样的模型，在该模型中，最终的一致性已经可以接受，更新是幂等的。例如，您可以在实体上实现一个版本，并有一个后台任务来确保版本同步。拥有DTC将提供事务重试功能，但它仍然无法解决重试后出现故障的情况——您仍然需要查看错误日志并制定处理错误的程序。
那么，我是否必须放入像NServiceBus这样的消息传递框架(甚至尽管读数据库和写数据库都在同一台机器上)有其他选择吗？
这取决于一些事情。在CQRS系统中，您经常遇到的是pub/sub的需求，其中几个子系统发布查询/缓存系统订阅的事件。如果您认为除了基本的点对点消息传递之外，还需要pub/sub，那么可以使用NServiceBus之类的服务。此外，即使出于可扩展性的目的不需要NServiceBus，我也不会立即回避使用它，因为我认为逻辑分区本身是有益的。另一方面，正如你所指出的，增加复杂性的层次是昂贵的，因此首先试着看看最简单的方法是否可行。
另一个问题是您是否需要一个单独的查询存储。如果你只有一台机器，为什么还要麻烦呢？您可以使用一些更简单的东西，比如读取模型模式，并且仍然可以获得CQRS的许多好处。
CQRS项目是否需要像NServiceBus这样的消息传递框架？
简短的回答：没有。
这是我第一次听说eulerfx提到的"读取模型模式"。这是一个很好的名字，但它还有更多：
"查询"部分背后的总体思想是查询数据的非规范化视图。在"读取模型模式"链接中，您会注意到用于填充读取模型的查询正在进行一些提升。在上面提到的例子中，所需的数据操作并没有那么复杂，但如果变得更加复杂呢？这就是去规范化的作用。当您执行"命令"部分时，下一步操作是去规范化数据并存储结果以便于阅读。所有繁重的工作都应该由您的域来完成。
这就是您询问有关信息的原因。这里有几种技术：
- 同一数据库、同一表、不同列中的非规范化数据
- 同一数据库、不同表中的非规范化数据
- 不同数据库中的非规范化数据
那是存储器。一致性如何？：
- 立即一致
- 最终一致
最简单的解决方案(快速获胜)是取消对域中数据的规范化，然后通过存储库保存域对象后，立即将取消规范化的数据保存到相同的数据存储、相同的表、不同的列中。100%一致，您可以立即开始读取非规范化数据。
如果真的想要，可以创建一组单独的对象来传输数据，但只编写一个简单的查询层会更简单，该查询层返回数据访问框架提供的一些携带数据的对象(在.Net的情况下，它将是DataRow/DataTable)。绝对没有理由花枝招展。总会有例外，但您可以继续编写数据容器。
为了最终实现一致性，您将需要某种形式的排队和相关处理。您可以推出自己的解决方案，也可以选择服务巴士。这取决于您和您的时间/技术限制：)
BTW：我在这里有一个免费的开源服务总线：
- 穿梭机。Esb
- 文件
欢迎任何反馈。但任何旧的服务巴士都可以(MassTransit/NServiceBus等)。
希望能有所帮助。