我开始认为CQRS分离方向是错误的，我们不应该在命令和查询之间分离责任，而是在业务需要强烈一致的操作和可能弱一致的操作之间。
这意味着如果业务需要读取您自己的写入，那么您不必向后弯曲以实现它，您只需在强一致性方面执行该读取操作。
它还允许更灵活的写入，因为您可以在业务允许的弱一致性方面进行编写。这种方法的一个实现可能是使用CRDT，强一致性方面是单个可寻址的持久复制品。
在一天结束时，企业真的关心某件事是命令还是查询？事实并非如此，企业关心的是一致性和顺序(banq注：数据的准确性 数据的完整性)，或者更具体地说，它关心的是什么时候保证，什么时候不保证。
通过命令和查询进行隔离并不能完全映射到业务所关注的内容，而是通过强弱一致性级别进行隔离。
因此，或许我们应该做出强烈一致的弱一致责任隔离：SWRS。在大多数情况下，它看起来与CQRS非常相似，只是功能更强大，更适合业务需求。
当然，实际实现这是有挑战的： 命令和查询是客观分类的，一致性要求可能是非常主观的（尽管技术上可行，例如跨实体连接，确实使分类有时是客观的）。
banq注：CQRS其实是技术架构上分离，也就是读写分离，而一致性是业务关注点，实际上DDD聚合是高一致性的设计结果，因此CQRS一般必须加上DDD，这样DDD帮助你实现一致性分离，哪些得到保证？聚合里的数据更新会得到高一致性保证，哪些不能得到保证，跨聚合操作等，这些是弱一致性，甚至可以通过流程来保证。