过去 6 个月的学习曲线充满挑战，CQRS 和 DDD 是罪魁祸首。
这很有趣，我们的项目已经完成了 1/2，我还没有时间深入研究的领域是消息传递框架。
目前我不使用 DTC，因此如果我的读取模型未更新，那么很可能会出现读取和写入数据库之间的不一致。我的读写数据库也将在同一台机器上。我怀疑我们是否会将它们放在不同的机器上。
我的系统中没有大量消息，因此我更关心的是系统的一致性和可靠性。
那么，我是否必须放入像 NServiceBus 这样的消息传递框架（即使读写数据库都在同一台机器上）还是有其他选择？是的，有学习曲线，但我想如果我不使用它，就会有很多东西需要学习。
另外，如果没有必要，我不想添加图层
想法？
目前我不使用 DTC，所以很有可能如果
我的读取模型未更新，那么我之间会出现不一致
读取和写入数据库。
就我个人而言，我不喜欢 DTC，并尽力避免它。相反，通常可以实现补偿机制，特别是对于像读取模型这样的模型，其中最终一致性已经可以接受并且更新是幂等的。例如，您可以在实体上实现版本，并有一个后台任务来确保版本同步。拥有 DTC 将提供事务性重试功能，但它仍然无法解决重试后发生故障的情况 - 您仍然必须查看错误日志并制定适当的程序来处理错误。
那么，我是否必须放入像 NServiceBus 这样的消息传递框架（甚至
虽然读和写数据库都在同一台机器上）还是我
还有其他选择吗？
这取决于几件事。在 CQRS 系统中经常遇到的是发布/订阅的需求，其中多个子系统发布查询/缓存系统订阅的事件。如果您发现除了基本的点对点消息传递之外还需要发布/订阅，那么请选择 NServiceBus 之类的东西。另外，即使您出于可扩展性目的不需要它，我也不会立即回避使用 NServiceBus，因为我认为逻辑分区本身是有益的。另一方面，正如您所指出的，增加复杂性的层数成本高昂，因此首先尝试看看最简单的方法是否可行。
另一个要问的问题是您是否需要一个单独的查询存储。如果您只有一台机器，为什么还要麻烦呢？你可以使用更简单的东西，比如读取模型模式 http://gorodinski.com/blog/2012/04/25/read-models-as-a-tactical-pattern-in-domain-driven-design-ddd/并且仍然可以获得 CQRS 的很多好处。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
