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