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