CQRS（Command Query Responsibility Segration） 和 CRUD

CQRS
CQ 两端数据库共享 （与CRUD 类似）
CQ 两端不仅代码分离，数据库也分离
扩展性更高
可异步
方便进行溯源与历史重现
对于Command类型的请求（需要修改数据），web层会走通过Event Sourcing更新聚合对象的流程，这时会有一个Event Handler的处理类监听相应事件，更新物化视图
对于Query类型的请求，web层会通过相应的DAO获取数据返回

CRUD
读写分离, 操作同一个实体对象
并发量多的时候，各种更新、查询都在这数据库里，会造成一些锁，性能上的影响，对数据库层是压力 依赖性较多

CRUD缺点 和 CQRS
我们一般的开发是增删改查，写在一个项目里，写一个Model，也就是entity,里面有各种表的field,查和改的时候我们一般用同一个model，框架可能用hibernate,mybatis等。但是同一个Model，可能会造成一些问题，比如你插入的数据，和你要查询的数据不匹配，比如查的数据用不着那么多列，这就造成了我们更新或者查询了一些额外的数据，造成性能的问题。当然你可以说，我不同的更新或者查询创建不同的Model，来减少额外的查询。但是还有个问题，当并发量多的时候，各种更新、查询都在这数据库里，会造成一些锁，性能上的影响，对数据库层是压力还有一个是写的sql越来越复杂，表越来越多，级联越来越多，相信很多人会有同样的体会。
这个时候就可以用CQRS了，简单的说就是数据的更新和查询用不同的接口。这里你可以理解为用不同的项目，查询我写在查询项目里，更新我写在更新的项目里。有同学会问，那我更新项目的时候如果想查询一些值呢？比如查询用户密码？对了这时候就涉及到服务之间的调用了。现在你可以把查询、更新项目理解为两个服务，提供不同的角色、服务，也就是提供不同的接口，先不要想具体实现。当然了，既然项目都拆开了，为了优化性能，我们可以吧数据库分开，一个用来写、一个用来查。
更新数据库的性能问题和数据不一致
虽然读写我们拆开了，但是写也会有各种性能问题，但是这有产生出另一个问题，数据不一致性。比如你更新了一个数据，而另一个数据库没有更新，可能有些地方出了问题。这个时候我们就要用到event sourcing了，他可以把每个动作先保留下来，然后一个一个执行，这样并发问题解决了，而且保留的动作我们还可以让他去更新读数据库，来避免数据不一致。

参考
https://www.cnblogs.com/netfocus/p/5184182.html
https://www.cnblogs.com/youring2/p/11028419.html