最近6个月的学习曲线不断挑战与CQRS和DDD的罪魁祸首。
它带来了乐趣，我们1/2的方式，通过我们的项目和领域，我还没有时间去钻研是一个消息框架。
目前，所以是一个非常好的可能引擎盖，如果没有更新我的阅读模式，然后我会读之间的矛盾和写入数据库，我不使用DTC。 也是我的读写数据库将在同一台机器上。 我怀疑我们将永远把它们放在不同的机器上。
我没有大量的邮件在我的系统，所以我关心的是更多地与系统的一致性和可靠性。
所以，我必须把像NServiceBus一个消息框架（即使读取和写入数据库是在同一台计算机上），或者我有别的选择吗？ 是的，有学习曲线，但我想会有很多的地狱学习，如果我不使用它。
另外，我不希望把一个层，如果它是没有必要的
思考？
目前，所以是一个非常好的可能引擎盖，如果没有更新我的阅读模式，然后我会读之间的矛盾和写入数据库，我不使用DTC。
就个人而言，我不喜欢的DTC，尽量避免它。 相反，它往往是可能实现补偿机制，尤其是对于像读取模型，其中最终一致性已经接受和更新是幂等。 例如，你可以实现在实体版本，并具有确保版本在同步后台任务。 有一个DTC将提供事务重试功能，但它在那里试之后发生故障时仍不能解决的情况下 - 你还是要观看错误日志，并有适当的程序处理错误。
所以，我必须把像NServiceBus一个消息框架（即使读取和写入数据库是在同一台计算机上），或者我有别的选择吗？
这取决于几件事情。 你经常在CQRS系统遇到的是需要的pub / sub，其中若干个子系统发布到该查询/缓存系统订阅事件。 如果你看到一个需要超越基本点至点的消息发布/订阅，然后用类似NServiceBus去。 另外，我也不会马上回避使用NServiceBus远，即使你不需要它可扩展性的目的，因为我觉得逻辑分区是对自己有利的。 在另一方面，正如你指出，增加复杂性的层是昂贵的，所以先试试，看看最简单可行的事情会工作。
问另外一个问题是，你是否需要一个单独的查询储存在所有。 如果你只有一台机器，何必呢？ 你可以使用更简单的东西，如读取模型模式 ，仍然获得了很多CQRS的好处。
做了CQRS项目需要像NServiceBus一个消息框架？
简短的回答：没有。
这是我第一次听到有关eulerfx提到的“读模型模式”。 这是个不错的名字，但还有更多的有点：
后面的“查询”部分的总体思路是：查询数据的非规范化的视图。 在“读模型模式”链接，你会发现，用于填充读模型的查询做一些提升。 在提到的例子所需要的数据操作不是那么复杂，但如果它确实变得更加复杂？ 这就是denomalization进来。当你执行你的“命令”部分的下一个动作是进行非规范化的数据，并存储为方便阅读的结果。 所有繁重应该由你的域来完成。
这就是为什么你是问有关的消息。 这里有几个技巧：
这就是存储。 如何一致性？：
最简单的解决方案（速赢）是在非规范化您的域名数据，然后通过资源库保存你的域对象后，你立即denomarlized数据保存到相同的数据存储，同一张表上，不同的列。 100％一致，就可以立即开始读的非规范化的数据。
如果你真的想你可以创建对象的一个单独的一堆传输数据，但它是简单的只写一个返回一些数据承载对象通过数据访问框架提供的（在.net中的情况下，一个简单的查询层会是DataRow / DataTable ）。 绝对没有理由获得幻想。 总是会有例外，但那么你可以继续写的数据容器。
对于最终一致性，您将需要某种形式的排队和相关处理。 你可以推出自己的解决方案或者您可以选择一个服务总线。 这是由你和你的时间/技术的限制:)
BTW：我有一个免费的开源服务总线在这里：
任何反馈将受到欢迎。 但是，任何老服务总线将做（MassTransit / NServiceBus /等）。
希望帮助。
