由于上一篇文章（Architecture: simple CQS），我一直在思考如何构建一个足够灵活的简单系统，以便以后扩展。
换句话说：我现在不认为需要一个完整的CQRS，但如果需要的话，我希望以后很容易发展它。
所以我正在考虑将命令与查询分开，但两者都基于相同的数据库。
查询部分很简单：基于视图的WCF数据服务，可以轻松查询数据。没什么特别的。
命令部分更难，这里有一个想法：命令当然是以异步方式执行的，因此它们不会返回结果。但是，我的ASP.NET MVC站点的控制器通常需要来自命令的反馈（例如，如果成员的注册成功与否）。因此，如果控制器发送命令，它还会生成与命令属性一起传递的事务ID（guid）。命令服务接收此命令，将其放入数据库中具有状态'processing'的事务表中，并执行（使用DDD原则）。执行后，事务表将更新，以便状态变为“已完成”或“失败”，以及其他更详细的信息，如生成的主键。
同时，该站点正在使用QueryService来轮询此事务的状态，直到它收到“已完成”或“已失败”，然后它可以根据此结果继续工作。如果轮询事务表并且结果为“已完成”或“失败”，则删除该条目。
副作用是我不需要guid作为我的实体的键，这对于性能和大小来说是一件好事。
在大多数情况下，可能不需要此轮询机制，但如果需要，可以使用此轮询机制。接口的设计考虑了CQS，因此对未来开放。
你认为这种方法有什么缺陷吗？其他想法或建议？
谢谢！
路德
答案 0 :(得分：5)
我认为您与您的方法非常接近完整的CQRS系统。
我有一个网站，我曾经做过类似你所描述的事情。我的网站braincredits.com使用CQRS进行架构，所有命令本质上都是异步的。因此，当我创建一个条目时，除了命令已成功提交进行处理（而不是它已处理）之外，对用户确实没有任何反馈。
但我在网站上有一个用户得分（他们的“积分”数），应该随着用户提交更多项目而改变。但我不希望用户继续按F5刷新浏览器。所以我正在做你提出的建议 - 我有一个AJAX呼叫，每隔一两秒就会触发，看看用户的信用计数是否已经改变。如果有，则返回新的金额并更新UI（通过一些动画来吸引用户的注意力 - 但不要过于华丽）。
您所谈论的是最终的一致性 - 用户所看到的应用程序状态最终将与系统数据（记录系统）保持一致。这个概念对CQRS来说非常关键，在我看来，这很有道理。只要您检索系统中的数据（无论它是否是基于CQRS的数据），数据就会过时。但是如果你假设并且假设客户端最终会保持一致，那么你的方法是有意义的，你也可以设计你的UI来解释它并利用它。
就建议而言，我会观察你做了多少民意调查，以及你发送和退回的数据量。通过民意调查，这听起来像你不是。但定位应该在您的网站上定期更新的内容，我认为您会很好。
查询端的WCF数据服务层是一个好主意 - 只需确保它只能启用读取（我相信你已经完成了）。
除此之外，听起来你的起步还不错。
我希望这会有所帮助。祝你好运！