我觉得不论是传统架构还是CQRS架构，都是不错的架构。传统架构门槛低，懂的人也多，且因为大部分项目都没有什么大的并发写入量和数据量。所以应该说大部分项目，采用传统架构就OK了。但是通过本文的分析，大家也知道了，传统架构确实也有一些缺点，比如在扩展性、可用性、性能瓶颈的解决方案上，都比CQRS架构要弱一点。大家有其他意见，欢迎拍砖，交流才能进步，呵呵。所以，如果你的应用场景是高并发写、高并发读、大数据，且希望在扩展性、可用性、性能、可伸缩性上表现更优秀，我觉得可以尝试CQRS架构。但是还有一个问题，CQRS架构的门槛很高，我认为如果没有成熟的框架支持，很难使用。而目前据我了解，业界还没有很多成熟的CQRS框架，java平台有axon framework, jdon framework；.NET平台，ENode框架正在朝这个方向努力。所以，我想这也是为什么目前几乎没有使用CQRS架构的成熟案例的原因之一。另一个原因是使用CQRS架构，需要开发者对DDD有一定的了解，否则也很难实践，而DDD本身要理解没个几年也很难运用到实际。还有一个原因，CQRS架构的核心是非常依赖于高性能的分布式消息中间件，所以要选型一个高性能的分布式消息中间件也是一个门槛（java平台有RocketMQ），.NET平台我个人专门开发了一个分布式消息队列EQueue，呵呵。另外，如果没有成熟的CQRS框架的支持，那编码复杂度也会很复杂，比如Event Sourcing，消息重试，消息幂等处理，事件的顺序处理，并发控制，这些问题都不是那么容易搞定的。而如果有框架支持，由框架来帮我们搞定这些纯技术问题，开发人员只需要关注如何建模，实现领域模型，如何更新读库，如何实现查询，那使用CQRS架构才有可能，因为这样才可能比传统的架构开发更简单，且能获得很多CQRS架构所带来的好处。