架构：简单的 CQS答案

【问题标题】：Architecture: simple CQS架构：简单的 CQS
【发布时间】：2011-10-18 13:43:27
【问题描述】：

我正在考虑为我的 ASP.NET MVC 网站应用 CQS，但这是一件非常简单的事情。我不是指 CQRS，因为我想对查询和命令部分使用相同的数据源，因此我不需要事件溯源和其他更复杂的模式。

所以，我的想法是：

我要实现的主要目标是：

这有意义吗？

【问题讨论】：

【解决方案1】：

所以，回答你的问题，是的，我认为这是有道理的。

我不确定您还在寻找什么。我认为您采用的方法是有道理的，应该可以满足您的需求。

在我看来，CQS 和 CQRS 非常相似，其中 CQRS 具有单独的读写存储的概念（有些人会认为甚至可能不需要写入存储）。事件溯源并不是 CQRS 的真正组成部分 - 可以说，它是一个附加组件，非常适合 CQRS 的分布式特性。

您放弃的方法是数据的一些可扩展性，因为您使用视图来展平数据。但是，如果您的应用不需要它，那么那里没有问题。

此外，阅读 Udi Dahan 的 article 关于何时避免 CQRS 可能很有用。它可能有助于证明你的决定是正确的。当他放开它时，引起了不小的轰动。但在他和 Greg Young 之间，他们是 CQRS 方面的专家。

我不确定我是否回答了您的问题或提供了帮助，但祝您项目顺利！我希望这会有所帮助。

【讨论】：

谢谢你，确实，我也读过那篇文章。我猜他是说你很少需要完整的 CQRS，甚至是任何分层。我在这里部分同意，这就是我只想应用轻量级 CQS 的原因。但我认为，从命令中分离查询的模式让事情变得更简单，但因为这是一个重大的设计决策，我想确保它是一种有效的方法。我现在唯一不确定的是是否使用 Guid 作为 DB 中的键，因为命令模式需要它，我担心性能。感谢 cmets！
命令端不需要 guid...但这只是获取客户端唯一 ID 的常用方法。通常最好在发出命令之前获取 id...guid 只是方便。您可以使用 int 或其他任何内容。由你决定。 :)。希望这会有所帮助！
“Guid 作为 DB 中的键，因为命令模式需要它，我担心性能” - 您可以使用不会对性能产生太大影响的顺序 GUID 而不是 INT/大整数。 (stackoverflow.com/questions/170346/…)
@David：我发现你的陈述“通常最好在发出命令之前获取 id”很有趣......你能详细说明一下吗？
@David：有趣的想法，然后想到了两件事：1.这是一个额外的调用，这不会影响性能吗？并且： 2. 如果多个命令同时进入怎么办，你如何确保你给他们唯一的 id？